修复一个 bug 后，必须验证用户真正看到的结果

千鹤酱项目今天的开发目标不是继续增加功能，而是把已有的消息列表整理成可观察、可测试、可维护的💎模块。页面目前包含搜索框、分类筛选、分页按✅钮和自动刷新四个入口，每个入口都可能触发数据请求。如果所有操作都直接调用同一个加载函数，短期内代码看起来很简洁，后续排查却会十分困难。

我先把消息列表拆成四类状态：等待加载、加载成功、加载失败和无匹配结果。每类状态都对应明确的页面表现，避免用一个布尔值同时表示“正在请求”和“列表为空”。状态名称越清晰，日志越容易阅读，后续测试也越容易覆盖。

千鹤酱项目今天先解决“能运行”之外的问题

开发初期最容易忽略的地方，是“功能可以使用”不等于“状态变化有规律”。用户输入关键字时，搜索框会连续触发请求；用户快速切换分类时，前一个请求可能尚未结束；自动刷新又可能在此✅时启动第三个请求。三个请求都返回数据后，页💎面必须知道哪个结果才是当前状态真正需要的结果。

把一次排查沉淀成下一次开发的检查表

前端排错还要关注用户感知，而不是只看控制台有没有报错。页面可能没有红色错误提❤️示，却存在闪烁、旧数据短暂出现、按钮重复提交和加载状态卡住等体验问题。每一次状态变化都应该有合理的起点和💯终点，用户才能判断当前操作是否已经生效。

先做最小复现，再决定采用哪种修复方式

《千鹤酱开发日记》今天记录的核心结论很简单：一个看似偶发的 bug，通常不是靠反复点击就能解决，而是要先稳定复现🚀，再缩小影响范围，最后验证修复是否真正覆盖了异常路径。今天遇到的问题发生在消息列表刷新时，页面偶尔会显示旧内容，重新打开页面又恢复正常。