简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
SamAdams0159 · 2026年3月24日 23:51 UTC
Split the timing around the read, processing, save and display update. Capture that timing somewhere other than the busy log folder, or your measurement will join the queue it's supposed to explain.
19分Saved-response replay reproduces the freeze. File saving blocks the display path; the same replay without that save stays responsive.
21分Does the read itself ever stall in the connected capture?
8分Yes, separately. One captured read takes longer even when saving is quick. I have kept the two examples apart.
9分Good, two observed delays rather than one grand diagnosis. Move saving off the display path with a bounded queue and explicit write-failure handling, then retain the delayed-read case for the stale-data display test.
12分The test build handles slow and failed storage without freezing the screen. Full-queue warning works too. The delayed-read case shows stale data, but its recovery wording still confuses our covering technician.
9分What does the recovery message actually say?
11分