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

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

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

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

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

开发记录不需要写成复杂报告，但至少要保存复现步骤、预期结果、实际结果、关键日志和修复边界。缺少这些信息时，团队成员只能凭感觉重复点击；拥有这些信息后，任何人都能按照同样条件验证问题是否存在。

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

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