※ 引述《holishing ( )》之铭言：
: 推 holishing: 如果过一阵子才正常，那就是已知问题 07/04 14:11
※ 引述《roujuu (老中)》之铭言：
: 是因为 ptt 这个bbs的程式写法的关系吗？
: “过一阵子才正常”是因为程式的写法并不是随时都去运算以更新相关方面的搜寻结果？
根据 PttBBS 的原始码，的确是这样的。
请见: https://github.com/ptt/pttbbs/blob/7b35778243/common/bbs/search.c
以下对处理逻辑的说明，主要是根据此程式码所得出的。
common/bbs/search.c 包含以下两个处理文章搜寻的函式：
select_read_should_build() 与 select_read_build()。
select_read_build() 会更新或重新建立搜寻结果，并建档储存。
而储存的档案，以下称之为“搜寻结果档”。
注意不同的搜寻条件会对应不同的搜寻结果档。
请见 mbbsd/read.c 中的函式 select_read()：
https://github.com/ptt/pttbbs/blob/7b35778243/mbbsd/read.c#L651...L720
select_read_should_build() 会决定是否需要更新或重新建立搜寻结果。
首先，如果搜寻结果档尚未建立，就需要重新建立搜寻结果。
接着，这个函式会检查看板的 SRexpire。
（SRexpire 应该是最近一次对此看板进行需要重新建立搜寻结果的操作的时间）
如果搜寻结果档比 SRexpire 还早建立的话，就需要重新建立搜寻结果。
检查完 SRexpire 后，会再检查搜寻结果档的更新时间（未更新过则为建立时间）。
如果搜寻结果超过 1 小时未更新，就会重新建立搜寻结果。
如果距上次更新未超过 1 小时，但超过 3 分钟未更新，
就会以目前的搜寻结果档为基础，更新搜寻结果。
如果距上次更新未超过 3 分钟，则会直接使用目前的搜寻结果档当作搜寻结果。
此外，当搜寻条件包含 m/s 标记或推文数时，
只要搜寻纪录的更新时间距上次更新超过 3 分钟，就会一律重新建立搜寻结果。
请见: https://github.com/ptt/pttbbs/blob/7b35778243/mbbsd/read.c#L700...L701
因此，若是遇到此类问题，目前暂时的因应方式是先等待 3 分钟后再重新搜寻。
若仍然遇到问题，则可尝试增加 m/s 标记或推文数的搜寻条件。
而从系统端解决的方式之一，则是找出会导致搜寻结果与文章列表不合的文章操作，
并使看板的 SRexpire 在这些操作后被更新，让下次搜寻能使用重新建立的搜寻结果。
※ 引述《roujuu (老中)》之铭言：
: 【板主:u10400068/zouelephant/redDest..】[希洽] Steam夏季特卖登场 看板《C_Chat》
: [←]离开 [→]阅读 [Ctrl-P]发表文章 [d]删除 [z]精华区 [i]看板资讯/设定 [h]说明
: 编号 日 期 作 者 文 章 标 题 人气:818
: 346277 +43 6/27 dzwei □ [闲聊] やなぎなぎ最经典的歌曲是哪首?
: 346278 + 6/27 dalyadam □ [实况] Forsen 玩(Bro Falls)恶搞?抄袭?
（恕省略以下内容……）
至于问题报告的内容，个人觉得以画面撷图为主来叙述的话，
读者会需要看图说故事，且文章篇幅会较大，因此阅读上可能会比较不容易理解，
而引用上可能也会有不甚方便之处。
如果能确定画面中有助于判断问题的部份的话，仅保留该部份有助于减少文章篇幅。
但若不清楚画面中须要保留的部份，而不便取舍的话，
如果每张撷图都有文字说明此撷图所对应的操作步骤，读者会更容易理解。
而如果能从问题报告的标题看出此问题的大致的类型，甚至大致的症状的话，
也可以帮助站方与协助维护程式的人员判断此问题的重要程度。