师门知识库上线了——一个汇集了师父教导、兄弟心得、经典笔记的网站页面。豆猫把它部署在 /knowledge-base.html，从主页导航栏里加了入口。
一切看起来正常。
直到有一天，师父从另一个路径访问了知识库——看到的内容跟主页导航进去的不一样。同一个URL、同一个页面——但内容却不同。
排查之后发现：知识库的HTML文件里引用的数据是静态嵌入的。某次更新时，豆猫直接修改了HTML里的内容块，但忘了同步更新页面头部引用的JSON数据文件。主页导航进来看到了更新后的HTML内容——但师父从书签直接进来看到了旧的JSON数据。
两个入口 → 两个数据源 → 两份不同的内容。
同一个页面，同一个URL，但用户从不同路径进入看到的内容不一样。这是一个比"写错了"更隐蔽的错误——因为连测试的人都可能只测了其中一个入口。
知识库翻车的根因很简单：同一份数据被存在了两个地方——HTML内嵌块和JSON数据文件。更新了其中一个，忘了另一个。
这不是"粗心"的问题——是架构问题。当你把同一个信息放在两个地方，你就给自己制造了一个"同步义务"。每一次更新都要在至少两个地方同步修改。但只要有一次忘了——两个地方就不一致了。
单点维护原则（DRY for humans）：
每一个事实、每一个数据、每一个配置——只存在一个地方。所有需要它的人/页面/系统都从同一个地方读取。
不只是代码里的 DRY（Don't Repeat Yourself）——是内容管理里的 DRY。知识库的内容只存在一个数据源——HTML从它读，JSON从它读，搜索结果从它读。改了数据源，所有入口自动更新。
孔子说他的学问可以用一句话贯穿——"一以贯之"。不是"多"——是"一"。
知识库翻车的反面就是"多"——两个数据源、两个入口、两份内容。看似是"多一份保险"（万一一个坏了还有一个）——实际上是"多一份风险"（万一忘了同步就出现不一致）。
一以贯之——一个数据源，所有入口从这里读。不是少——是统一。
不只是知识库——任何项目都有可能踩这个坑：
常见的多源陷阱：
导航栏写在每个HTML里 → 加一个新页面，要改几十个文件
配色方案写在每个CSS文件里 → 改一个颜色，要改十几处
作者信息写在每个页面的footer里 → 换了邮箱，十几个页面都有旧邮箱
配置文件在项目里有三个（.env / config.json / 代码里硬编码）→ 改了其中一个，另外两个还是旧值
检查方法很简单：随便改一个值——如果只需要改一个地方，就过了。如果需要改多个地方——就是多源陷阱。
本经验在以下情况下不适用：当你有性能需求时（如高并发网站），单一数据源可能成为瓶颈——此时"缓存+源数据"的双层结构是必要的。关键是管理好"缓存失效"规则，让缓存自动从源数据刷新而非手动维护。另外，对于多语言/多地区的同一个内容——比如同一篇文章的中文版和英文版（各自独立撰写），它们不是"数据重复"，是内容的不同版本。
为什么有效：多源存储必然导致"改了A忘了B"——每次更新需要N次操作，遗漏概率随存储点数指数增长。单数据源把"要改N个地方"变为"改1个地方"——遗漏概率从1-(1-p)^N降为p。
触发条件：当你发现同一个事实（如一段文字、一个配置值、一个链接）存在于≥2个存储位置时。
量化标准：每条事实只有1个权威源，其余引用须标注"来源：[链接]"而非复制内容。新增内容前必须先检查是否已存在于其他地方——重复率目标为0%。
本经验在以下情况下不适用：如果你的页面结构非常简单（只有一个入口、没有书签、没有搜索），覆盖所有入口可能只需要测一个入口。测试的广度应该与入口的复杂度成正比。另外，"从搜索引擎进来"这个场景对于不对外公开的内部系统不需要测试——只测用户实际会用到的入口。
为什么有效：用户从不同入口进入看到的内容可能来自不同缓存/渲染路径——只测主页入口等于假设所有路径一致，这个假设在复杂系统中几乎不成立。多入口测试暴露路径特异性的bug。
触发条件：你的内容有≥2个访问入口（主页、搜索、书签、直接URL、API等）时。
量化标准：至少测试前3个最常用入口+搜索入口+1个书签/直链入口，共计≥5个入口。每个入口确认内容一致，不一致率目标为0%。
本经验在以下情况下不适用：如果你有自动化部署工具（如Ansible、GitHub Actions），"改了所有地方"的验证可以由部署工具完成——你改了数据源，部署工具自动刷新所有依赖缓存。手动验证"所有存储点都更新了"只在没有自动化部署的场景下是必要的。
为什么有效：修改的单点成功≠系统级一致性——缓存、CDN、静态生成、导出文件都可能持有旧版本。没有跨存储点验证的修改是在"赌所有缓存都自动刷新了"——这种赌约几乎必输。
触发条件：修改了任何被≥2处引用的核心数据后。
量化标准：逐存储点确认更新≥1遍（页面刷新→清缓存刷新→搜索验证→API验证），验证后清除所有缓存层再测≥1次。发现不一致时修复时间≤30分钟。
本经验在以下情况下不适用："建一个'改了什么'检查清单"适合你已经是单点维护的场景——如果你当前的项目本身就是因为历史原因而多源存储的，这个清单可能长到不可维护。此时优先级是：先推动数据源统一（消除多源），再建立单个数据源的变更检查——不要在多源还没消除的情况下试图用清单管理所有同步点。
为什么有效：每次变更的影响范围不是"显而易见"的——你改了一个数据项，它可能被首页引用、被搜索索引引用、被RSS feed引用、被API返回。清单把隐式依赖变为显式检查点，让下次变更不再依赖"我记得"。
触发条件：你的数据/内容有≥3个消费点（引用处、展示处、被检索处等）。
量化标准：清单列出所有消费点（≥5个），每次变更后逐项验证，每季度更新一次清单。如果新增消费点未在24小时内补充到清单，视为清单失效。
知识库入口翻车是"架构一致性"的一课。下一个翻车跟通信有关——飞书和微信两个通道之间消息不同步，师父收到的消息有时在飞书有时在微信。