网站缓存：多系统同时生成网址规则时，怎样定义唯一责任方
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9c1a56e77f16.html
📄
网站缓存：多系统同时生成网址规则时，怎样定义唯一责任方
唯一责任方应当是“网址规则的最终写入方”，而不是缓存层本身。更具体地说，先确认哪个系统拥有最终 URL 命名权，再让其他系统只消费、不生成；如果两个系统都必须生成 URL，则必须划定命名空间并指定合并顺序，否则缓存键会随规则来源漂移，旧内容退出时无法判断该删哪一份。
先判断两种条件：谁在写 URL，谁只是在读
条件一：只有一个系统能改 URL 结构，其他系统只是把已有 URL 拼上参数或做跳转。这时责任方很清晰，就是那个能改路径、能改目录层级的系统。缓存层、CDN、反向代理、前端路由都只应接受它输出的结果。
条件二：多个系统都能生成 URL，例如旧 CMS 仍在输出栏目页，新应用也在生成同一批内容的详情页。这时不能靠“谁先上线谁负责”来定，而要先做一次 URL 归属盘点：把每个 URL 模式对应到唯一生成源，凡是无法对应到单一生成源的，标记为冲突项。
判断依据不是系统数量，而是“谁能让 URL 在无缓存状态下发生变化”。能改变最终 HTML 中链接结构的系统，才具备生成权；只能改写响应头、查询串或重定向的系统，属于消费方。
实施动作：先冻结生成权，再处理缓存退出
第一步，选定唯一责任方，并让它输出一份 URL 规则清单，至少包含路径模式、参数处理方式、大小写与末尾斜杠规则、以及哪些旧模式已废弃。这份清单是后续缓存清理和重定向的唯一依据。
第二步，把其他系统的生成行为改为只读或代理。例如旧系统不再直接输出链接，而是读取责任方提供的映射；如果短期无法改造，就在边缘层做归一化，把非责任方生成的 URL 统一重写到责任方格式。
第三步，针对要退出的旧内容，先确认它在缓存中的键由哪套规则产生。如果旧 URL 和新 URL 指向同一内容但缓存键不同，直接删缓存不会让旧入口消失，必须同时处理重定向和链接输出。这个动作的结果会直接影响下一步：若旧 URL 仍被其他系统生成，就不能只靠缓存过期来退出。
保留有价值部分时，例外怎么划
旧系统或旧合作关系退出时，常见例外是“旧 URL 仍有外部链接或用户收藏”。这时可以保留旧 URL 作为重定向入口，但生成权仍归责任方，旧系统不再新增或修改这类 URL。
另一个例外是分站或子目录由不同团队维护。此时唯一责任方可以按命名空间拆分：主站路径由主责任方定义，子目录路径由子责任方定义，但两者必须在同一份规则清单中登记，且缓存键的前缀必须能区分来源。没有登记的子目录 URL 不应进入缓存清理范围，否则容易误删仍在使用的内容。
假设一个场景：旧博客系统输出 /blog/old-post，新系统输出 /articles/old-post，两者内容相同。若责任方定为新系统，则旧路径应转为重定向，旧系统停止生成；缓存清理以新路径为主，旧路径只保留重定向响应。若责任方暂定为旧系统，则新系统必须改为引用旧路径，否则同一内容会出现两个缓存键，退出时无法判断哪一个该保留。
验证责任方是否真的唯一
验证方法不是看文档，而是看无缓存响应中的链接来源。抓取一个页面，关闭缓存或使用绕过缓存的请求，检查页面内链接、站点地图和重定向链是否都指向同一套 URL 规则。如果站点地图仍由旧系统生成，而页面链接由新系统生成，就说明生成权没有真正统一。
还需要分别核查不同搜索引擎对旧 URL 的处理情况。robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录。因此，旧内容退出时，不能把“已禁止抓取”或“已提交新站点地图”当作唯一责任方已生效的证据。更稳妥的做法是保留重定向、更新内部链接，并观察服务器日志中旧 URL 的请求是否仍来自站内。
如果请求量下降，也不能单独证明处理正确，因为可能是外部链接自然减少、缓存命中变化或抓取节奏波动。下一步应检查旧 URL 是否仍出现在责任方输出的链接清单中；只要还在，就说明生成权尚未收口，缓存规则还会继续分叉。
