一句话总结

将报价自定义价问题从影响盘点推进到 78 条生产历史数据逐条补偿并提交，同时完成销售明细超长查询保护、日志收益复核和多项跨服务根因/方案收口。

今日成果

  • 完成报价动态自定义价历史异常的生产修复：先确认候选仍为 78 条，再逐条锁定、校验规则与指导价、只更新自定义价并立即回读，全部满足原规则计算结果后提交；正常 0 值未纳入，其他价格字段和 MQ 未改。
  • 完成销售明细查询、成本查询和两类导出的最长 6 个月保护；定位长日期全量组装导致的 256MB OOM，并修复旧版 iframe 错误提示上下文，提交 c1bf76d489，预发错误响应与静态检查通过。
  • 完成生产日志同窗口收益复核：09:00–09:42 总容量下降约 9.8%、AES 请求日志下降约 23.5%；00:00–14:59 的 providers/default 容量下降约 33.8%，但全天口径仍待下一工作日确认。
  • 完成预发审核源数据补全并验证审核链路：页面可自动带出管理员与手机号，审核日志和 DGJ 侧生成的客户源数据均已回读；未改请求参数、代码或生产数据。
  • 将 AES 5 秒超时从“单请求慢”收敛为“大分页并发占满两个节点的同步 Worker，后续请求排队后由调用方先超时断开”；同时完成 Apollo→Tools Worker→Redis→DGJ 读取链路和 DGJ 本地加密开关方案设计，尚未实施。
  • 明确应收余额缓存只应缓存聚合结果，需覆盖发票/付款全部写入方，在事务提交后失效并防止击穿；当前为方案已明确待实施。

问题与风险

  • 销售明细限制已在代码和预发错误响应层面验证，发布后仍需回归旧版正常/超期查询与导出，以及确认 V2 不受影响。
  • AES 4000 行请求的最终业务入口、异常 Worker 退出原因和合理限流/分页策略仍未完全闭环；本次未修改线上代码或服务。
  • 应收缓存如果只在收款页面失效会漏掉支付中心、订单中心和异步任务等写入方，必须先完整盘点再实施。
  • DGJ 分支中仍存在与本次销售明细无关的提交；自定义校验已移出 vendor，但 PHP runtime 检查受本机 ICU 缺失影响，最新提交尚未推送。

验证与证据

  • 私有复盘：`2026-09-15.md`；原始采集：`2026-09-15.json`。
  • DGJ2 严格知识审计：16 个活动包、5 个待沉淀、7 个候选、1 个高优先级、1 个需晋级、0 个数据错误；成熟度 L1/目标 L2。
  • 报价补偿证据保留在 DGJ2 对应变更包和逐条补偿清单；公共日报不保存临时业务 ID、账号、Cookie 或完整日志。
  • 生产日志使用精确日期索引和同窗口只读统计；预发审核使用源数据回读与审核日志回读；销售明细使用错误 JSON、Network 和本地静态检查。
  • 本次 Tencent Cloud 工作区快照、文档发布远端回读和公开文章/API 验证在归档结束时执行并记录。

下一步

  • 发布销售明细限制后完成四场景回归，并补一次新版隔离验证。
  • 继续确认 AES 大分页的真实上游入口，形成分页/并发/限流的最小实施方案后再改 DGJ。
  • 完成应收缓存的写入方矩阵、事务后失效和并发旧查询回写测试，再决定是否编码。
  • 下一工作日补齐 9 月 15 日全天日志量和 AES 观察口径，避免将半日统计写成最终收益。