《千鹤酱开发日记》里的第一个异常：列表总是慢一拍

千鹤酱开发日记本次修复后的验证重点，不是点📢击一次搜索按钮，而是覆盖多个操作组合。真实用户不会严格等待请求完成后再操作，因此测试需要故意制造快速输入、重复点击、切换筛选和离开页面等情况。

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

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

我在本次记录中优先使用请求编号，因为该方案不会改变接口行为，也不依赖特定网络库。每次发起请求时保存当前编号，响应返回后比较编号；编号较旧的结果只记录日志，不进入页面状态。这样既保留了异常信息，也避免过期数据污染界面。

本次记录也提醒我，功能开发的速度不能只用新增页面和完成按钮来衡量。一个可靠的模块需要明确状态、可控请求、稳定复现和针对性测试。下一次继续扩展千📢鹤酱项目时，我会先为高频交互补上请求生命周期记录，再考虑增加动画和自动化功能，让每一个新需求都不会把旧问题重新带回来。

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

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

千鹤酱项目的最小复现只保留搜索输入、请求函数和结果列表三个部分，移☀️除了自动刷新、分页和复杂动画。缩小范围后，异常从“偶尔发生”变成了可以稳定触发：连续输入两个关键词，并人为让第一个请🍀求延迟返回。

最小复现的价值在于，它能区分真正原因和伴随现象。假如删掉分页后问题仍然存在，分页就不👍是首要嫌疑；假如禁用自动刷新后问题消失，就要继续检查刷新任务是否重复创建。排查过程不应一次修改很多地方，否则修复成功也无法判🎆断究竟是哪一处改变发挥了作用。

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

当前场景可以采用三种处理思路。第一种是给请求分配递增编号，只有编号等于最新编号的响应才能更新页面；第二种是在新请求开始时取消旧请求，减少无效网络和渲染；第三种是比较响应中的查询条件与当前条件，条件不一致时拒绝写入。实际项目可以结合使用，但必须明确谁负责判断结果是否过期。

《千鹤酱开发日记》这次排查留下的最大收获，是把“偶发 bug”转化成了可描述的工程问题。以后遇到列表内容不稳定，我会先确认请求是否并发，再确认响应是否🌟按发起顺序返回，最后检查页面状态是否允许旧数据写入。