最近整理的真实排障、后端、运维和 AI 辅助开发记录。
报表能正常显示一页筛选结果，导出相同范围却明显更慢。流程已经使用流式工作簿写入器，批次大小和写入器配置自然成为排查方向。 沿数据提供层继续检查，发现每个输出批次都会重新进入列表分页流程：计算总数、执行分页查询、转换这一批数据，再追加到工作簿。文件在逐批写入，数据库执行却不断重新开始。 本次本地修复让 …
每日计数可以回答发生了多少次请求，却无法说明每次请求检测到的名称、精确时间和读取方式。当页面已经显示非零的 AI 请求总数，却没有任何逐次访问可列出时，这个差异就会直接暴露出来。 系统需要为新流量保存更丰富的记录，同时保留旧总数原本的含义。如果把一个历史计数拆成几条看似合理的明细，界面会更整齐，证据 …
用户在列表中选中多条记录后点击删除，请求返回 HTTP 500。数据库最早错误来自一条拼接明细文本的分组查询，这条查询原本服务于页面展示。删除操作因此继承了一个自身并不需要的读取依赖。 问题还跨越了多个层次：浏览器逐条发起删除请求，控制层没有稳定保留服务结果，服务层先加载扩展展示对象，再定位需要删除 …
一个运营页面把两项顶部异常数标成“今日”。只读查询按本地当天筛选后，得到的记录数明显更少。排查期间业务持续流转，数量自然会变化，但每轮比较都稳定出现一批属于昨日的记录。 源码中的日期范围解释了差异：下界是昨日零点，上界是今日最后一秒。查询返回的异常记录都真实存在，区间却覆盖了两个自然日。页面标签与实 …
一个运营看板开始把订单提前推进到后续阶段：收货刚完成，页面就显示卸货或检验；订单已经发运，报表却仍把它标成较早的核对阶段。真实业务交易还在继续，状态报表描述的操作边界已经偏离现场。 故障同时涉及读写两端。报表接受了流转表中的全部记录，其中包括没有开始时间的行，以及为未来阶段提前生成的占位记录。另一个 …
用于升级演练的数据库从一份有效快照复制而来。复制完成后，来源端又增加了结构和字典变化。测试应用开始验收前，目标库需要补齐这些变化，才能得到可比较的基线。 目标库已有部分升级结果，还保留了一项比来源定义更宽、经过验证的兼容改进。同步范围也明确排除了业务记录。若直接顺序执行一组无条件 …
这个网站既是工程笔记，也是我公开展示工作方法的地方。每个值得记录的案例都从可观察现象开始，沿真实数据和运行链路定位，控制改动范围，并以验证结果结束。