之前v0.1.7版本开始，把逻辑更新为了更加高效的事件回调方式，之前还有一个帖子讨论这个问题。

当时还出现了未注册65534标签，导致修改帖子不生效问题，v0.1.8修复了。让修改帖子的标签到达后，使其能被事件触发。

之前补上的逻辑在这里：https://github.com/stalltrix/kepweb/blob/e7a2832cf15cc6fdd5d51ea73280ac9974a1c7c8/webserver.go#L806




但是后续补上的逻辑，似乎并没有理解之前开发者的设计意图。事件回调的停止，在于查找到是否存在此帖子（即帖子是否已被加载）

通过一个 "二维指针.Load()"，判断帖子是否已加载完毕，从而结束此次唤醒。
https://github.com/stalltrix/kepweb/blob/e7a2832cf15cc6fdd5d51ea73280ac9974a1c7c8/webserver.go#L857





此逻辑在非特殊标签（0-11）的时候，是完全正常预期工作的。但是后面补上的逻辑notify.Reg_fs(65534,callback_renew)。直接注册了特殊标签65534。然而特殊标签并非“帖子”，并不会因为找到帖子而结束事件回调而“停下来”。每次接收到修改帖子标签，反而会持续大量唤醒。

然后会进入到这个逻辑
https://github.com/stalltrix/kepweb/blob/e7a2832cf15cc6fdd5d51ea73280ac9974a1c7c8/webserver.go#L579

虽然最终由于`timestamp > o_post.Replies[nowV.Y].Time`这个逻辑，会把错误唤醒回调挡下来return。

最终依然会得到正确的数据。但是内部会出现大量事件回调的唤醒，一旦65534标签到达，会被大量唤醒，唤醒后又被return，然后再继续唤醒。并不会停止直到持续遍历完此标签数据。


此现象在最新版本v0.2.5依然存在，感觉这种设计并不是预期的目标，应该解决下。

bug王来了，好奇bug王是又是怎么发现这个问题的。我看服务器的日志一切正常啊

@duso(nk6eqj) 你服务器"log_level"应该是默认的"info"。把日志改成"log_level":"debug"就能看到更详细的信息了，回调触发也会打印debug日志的。

还有bug王是怎么回事？ bug王应该是php才对

bug王估计是运营反馈区大量bug都是楼主找到的。不过楼主有兴趣其实可以直接提交PR。

@007幽灵(v3awah) 现在没兴趣提交PR了，主要是以前还被抄过PR然后又closed掉。有PTSD了，也没动力了

提PR要自己想解决方法，还有测试。工作量不是一个级别。

如果不是这里讨论氛围好，站长反馈及时，否则我后续这种bug报告都不会提。

说实话，最初是看到其他人提bug。然后也其他提了个bug试试水，发现会有人在意，然后才继续的提的

已解决，change_tag使用了单独标签终止符。更新kepweb v0.2.6或者kepweb-multi v0.1.13即可