主域名选择：发布系统把配置覆盖回旧值时怎样追踪来源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3cf1a8a8bdcb.html
📄
主域名选择：发布系统把配置覆盖回旧值时怎样追踪来源
先不要改发布系统，也不要再发布一次。把当前线上生效的页面当作唯一事实来源，从页面里保存的域名事实往回追：谁在什么时间、通过哪条链路写入了旧值。追踪的目标不是找出“谁错了”，而是把“我记得改过”变成一份可核对的写入记录。
先固定“当前事实”，而不是先争论谁改过
多个角色对同一事实有不同理解时，最有效的做法是把分歧转成可核对的项目。你需要先确认三件事：线上实际返回的 canonical、站点地图里出现的域名、以及发布流水线里最近一次成功构建的产物。三者不一致时，先记录差异，不要急着下结论。
具体动作：打开一个受影响的页面，查看源码中的 canonical 与 hreflang 指向；再取一份站点地图，看里面写的域名；最后从发布产物目录取同一路径的文件。把三份值并排写下，标注各自的时间戳。结果会直接决定下一步：如果只有线上是旧值，问题在发布或缓存环节；如果产物本身就是旧值，问题在构建前的配置源。
把配置来源分成三层，逐层排除
发布系统覆盖回旧值，通常不是单一原因。可以按写入顺序分成三层，每层都有可区分的证据。
- 代码仓库层：配置文件、环境变量模板、构建脚本里的默认值。证据是提交历史与分支合并记录。如果旧值出现在这里，说明某次合并把新值覆盖了。
- 发布平台层：流水线变量、环境配置、部署时注入的参数。证据是每次构建的变量快照。如果仓库是新值而产物是旧值，重点看这一层。
- 运行时层：CDN、反向代理、缓存或数据库里的动态配置。证据是响应头、缓存键和配置读取日志。如果产物是新值而线上是旧值，重点看这一层。
假设一个场景：仓库里 canonical 已改成新域名，构建产物也是新域名，但线上仍返回旧域名。此时可以做一个动作——在发布平台临时关闭缓存或换一个不经过缓存的路径请求同一页面。如果返回新值，说明旧值来自缓存层；如果仍是旧值，说明还有一处运行时配置在写入。这个结果决定了你是去清缓存，还是继续查配置中心。
用“写入时间”对齐，而不是用“最后修改时间”
很多追踪失败，是因为大家看的是文件最后修改时间，而发布系统实际读取的是配置项的写入时间。两者可能相差很远。把仓库提交时间、构建开始时间、部署完成时间、线上首次返回旧值的时间列成一条时间线，找出旧值第一次出现的位置。
关键判断：如果旧值第一次出现的时间早于最近一次构建，那它可能一直没被真正覆盖，只是这次才被注意到；如果晚于构建完成时间，那更可能是运行时写入或缓存回源。这个区分会影响后续动作——前者要检查配置是否真的被读取，后者要检查写入权限和触发条件。
把追踪结果转成一份可核对的记录
追踪结束后，不要只口头同步。把下面几项写进同一个文档，供后续核对：
- 受影响的域名值与页面范围；
- 旧值第一次出现的时间点；
- 判定所属的层级（仓库、平台或运行时）；
- 支持该判定的证据类型，例如提交记录、变量快照或响应头；
- 下一步动作及其负责人。
这样做的好处是，当旧值再次出现时，你可以直接对照这份记录，判断是同一原因复发，还是出现了新的写入路径。如果同一层级反复覆盖，说明需要在该层加校验；如果每次层级不同，说明发布链路缺少统一的配置来源。
什么时候该停止追踪，先做隔离
如果旧值仍在持续写入，而追踪需要较长时间，可以先做隔离而不是继续追。隔离的动作包括：暂时冻结该配置项的写入权限、把发布流程改为只读模式、或让线上先返回一个明确的中间值。隔离不是修复，但它能阻止影响范围扩大，并让后续的追踪在一个稳定的环境里进行。
需要说明的是，抓取限制、站点地图和 HTTPS 状态都不能单独证明配置已经正确。robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。追踪配置来源时，这些信号只能作为辅助，不能替代对写入链路的核对。
最终你要得到的不是一句“已经改回来了”，而是一条能重复验证的路径：从线上事实出发，经过哪一层，回到哪个写入点，以及下次如何更早发现它。
