好久没回来了，既然来了就随便说说。之前无意发现这件事大概在这里，现在发帖采用的是异步方法，即：发帖后先返回成功，后台进行发帖任务，异步发帖任务失败后打印失败日志。

异步可能是体感考虑 -- 让人感觉发帖很快，程序也很快。但是有一件可能没有意识到的事情，就是丢帖子的风险，异步失败后虽然打印失败日志，但是帖子丢了。并且用户还感觉不到，以为“发帖成功”了。

同步虽然体感卡一点，但是用户会意识到发帖失败，然后自行保存帖子，丢帖子对论坛程序来说是一件比较严重的事情。




并不是说异步不好，异步与同步都有各自的优势。不过现在异步有丢帖子的风险还是修一下好

大神都这么晚了还不睡觉啊，不过我用了这么久都没感觉到这个问题，正常情况下应该不会失败吧？

确实如楼上所说，默认情况下webui连接的是local_token，正常来说不会失败。不过处理一下特殊情况比较好

直接改同步不就行了吗，发帖的时候卡几秒也没人在意吧

我记得在 v0.1.0正式发版之前，还是在内测群的时候，最开始就是同步的。有人说嫌卡然后才建议改为异步的。

我也看了下这段代码，后台异步任务失败后，只打印失败日志，帖子确实丢了。

大佬不愧是大佬，有未卜先知之感。看大佬的发言，每次在bug出现之前就能发现。

说实话，这么久了我也没有出现过任何丢帖子的事情。我感觉这个应该是一个不容易触发的条件。

发帖是io操作，比较耗时间，估计是这种原因才改成异步的

这难道就是传说中的速度与稳定不可兼得？不过当小孩子做选择，我想全都要。有没有大神想一个又快又稳的方法

@coco(effhnu) 你在想P吃，你都知道鱼鱼熊掌不可兼得了。又快又稳估计会复杂度爆炸

@coco(effhnu) 不，又快又稳说不定真的可以。看楼上的反馈发帖失败率都很低，说不定搞一个健康检查就能解决。让发帖介于异步与同步之间

我感觉确实应该修一下，特别是长文没了这种基本很打击人

不不不，用户觉得卡，不一定是真的卡。有时候你加一个“正在发送”的转圈圈动画。用户就会感觉很快了

kepweb 已更新 commit 6e85442，就是把async改成sync+转圈圈动画缓解的。介于异步与同步之间的这种暂时太麻烦了

这次顺便发版了v0.2.9，之前有坛友问一直不发版。v0.2.9与v0.2.8跨度比较大，蕴含多个更新，不过兼容性依然完全向下兼容