每日计数可以回答发生了多少次请求，却无法说明每次请求检测到的名称、精确时间和读取方式。当页面已经显示非零的 AI 请求总数，却没有任何逐次访问可列出时，这个差异就会直接暴露出来。

系统需要为新流量保存更丰富的记录，同时保留旧总数原本的含义。如果把一个历史计数拆成几条看似合理的明细，界面会更整齐，证据却会变弱。因此，这次演进保留旧聚合作为聚合，只为实际观测到的新请求写入事件，并向读者明确标出两者边界。

信息在聚合时已经丢失

旧模型保存文章 slug、语言、规范化 AI 家族、UTC 日期和请求次数。这些字段足以计算每日总量，却没有单次请求的客户端名称、时间、检测来源，也没有记录客户端读取 …

用户在列表中选中多条记录后点击删除，请求返回 HTTP 500。数据库最早错误来自一条拼接明细文本的分组查询，这条查询原本服务于页面展示。删除操作因此继承了一个自身并不需要的读取依赖。

问题还跨越了多个层次：浏览器逐条发起删除请求，控制层没有稳定保留服务结果，服务层先加载扩展展示对象，再定位需要删除的持久化记录。后续步骤一旦失败，页面很难确认整批选择究竟已提交、部分执行，还是完整回滚。

修复为破坏性操作建立了一个清晰边界：服务端一次接收整批目标，读取精确的持久化模型，先校验全部记录，再在同一事务内按依赖顺序删除，最后把真实结果返回页面。

沿最早错误定位，再继续检查调用链

数据库日志记录了聚合投 …

一次单据复制请求被数据库自定义错误拒绝。提示指向库存质量不允许使用，但现场库存有足够实物数量，质量属性也处于允许状态。

数据库仍然掌握了拒绝写入的有效依据。可用量由实物数量减去已分配数量得到，而两层冗余计数都显示全部数量已经分配。权威预留记录中却找不到对应业务明细。触发器因此计算出可用量为零，并执行了既有业务约束。

本次处理保留了这条约束，在并发保护下修复幽灵占用，同时调整应用边界：多行复制失败时先完成事务回滚，再把数据库错误转换为用户可读的业务提示。

把数据库拒绝当作证据

排查先定位中止事务的具体语句和业务约束。复制流程已经准备好新表头，写入明细时触发数据库检查。检查会计算满足质量条件且尚未 …