存量不会自动跟上新逻辑

更新于 2026-09-21

存量不会自动跟上新逻辑

# 存量不会自动跟上新逻辑

结论

你反复遇到的不是「改错了」，而是**「改对了，但只有新东西享受到了」**。 新代码/新协议/新渲染路径都上线了，存量（旧数据行、旧文件、旧模板、已同步过的层） 却还按旧规则存在，并且不报错 —— 于是症状是「改了没用 / 修了还是坏的」。 判定标准：这个改动，存量对象会不会再经过一次它？ 不会，就得单独带过去。

六处证据

出处改对的新逻辑谁没跟上症状
INSERT OR IGNORE会让旧行不更新封面提取逻辑修对，新行字段正确已存在的旧行被 IGNORE 跳过界面仍旧值，只有新文章对
多源更新按维度取真源本地协议改造已定稿「还没同步的层」没人推文档与运行时各说各话
导入要保留来源类型以选对渲染链新入口归一化后落库正确已入库的内容没补 kind老剪藏仍走错渲染链
兼容fallback会让内容重复渲染新模板写了 section.body 新槽旧 fallback 路径仍活着并再渲染一次同一份内容显示两遍
仓库残留会误导对现状的判断运行时已完全走 DBprototypes/、旧文档、旧 migration 默认值仍在仓库人和 agent 反复误判架构
以前能用最近坏了先查自己改了什么补丁修好了图片依赖旧结构的页面（全局剥标签的副作用）旧问题换个形态暴露

旁证：零延迟零尝试说明请求没发出去 —— 「强制让账号重新进路由」的运行时开关被持久层恢复流程覆盖， 同一形状：你改的那一层，不是下次真正被读的那一层。

综合判断

  1. 一次改动的作用面，只覆盖「未来经过这条路径的对象」。 存量对象已经过去了，它们既不会回放， 也不会报错 —— 所以修复的验收必须分两栏：新对象对不对 + 存量怎么办（回填 / 迁移 / 显式声明）。

  2. 「旧路径还活着」比「旧数据还在」更危险。 旧数据只是不变；旧路径（fallback 渲染、 残留原型、被恢复流程覆盖的开关）会主动参与当前行为，把新逻辑的结果再污染一遍。 所以下线旧路径和写新路径是同一件事的两半。

  3. 可迁移的动作：任何一次「改逻辑」之后，追问三句 —— 「存量对象怎么办？」「旧路径还在跑吗？」「我改的这一层，下次真的会被读吗？」 三句里有一句答不上来，这次修复就只完成了一半。

与既有 synthesis 的关系

  • 分层要落到运行时才有效 —— 讲「没人读就等于不存在」；本条讲**「有人读了，但存量没经过它」**。 两条合起来是「约束生效」的完整条件：有执行者，且所有对象都会经过执行者。
  • 可复用物与不可复用物分开 —— 存量问题本质是「旧东西没被清出去」，与按寿命分层同源。

为什么这是 synthesis

单看每一页，都是某个项目里的一次「修了但没全好」（回填没写、同步没推、旧模板没下线）。 并排之后才看得出它们共享同一个失败形状：新逻辑只对新对象生效。 这个形状与领域无关，可以直接带走。

相关