激活只是第三步：一次 WordPress 主题切换的四阶段变更管理
切换主题这件事，在 WordPress 后台点一下“激活”，耗时不到一秒。但围绕那一秒，我花了四天准备、三天监测，中间还踩了两个坑。
上一篇讲的是换完之后碰到了什么麻烦。这一篇往回退一步，讲那个“换”本身是怎么管的。核心就一句话：激活是整个流程里最没有技术含量的一步，真正花时间的是它前后的四件事，而每一件都有自己安静的方式让你翻车。
系列：paddy-newsprint 主题开发记 · 续篇
前置阅读：做了一个报纸风格的 WordPress Markdown 主题 · 换装之后：75 到 93，三条军规的生产环境成绩单 · 上线不是终点：主题没写错，麻烦都在它脚下 · 越堆越厚：一张防护链的地图和它的盲区
主题分类：实践复盘 阅读时间：约 11 分钟
阶段零：本地先过一遍，别拿生产环境当调试器
主题在上线之前，我在本地搭了一套完整的 WordPress 环境，数据库是从生产拉下来的快照，插件列表一致。这一步的意义不是“看看能不能跑”，是“在不会弄坏任何人的前提下，把所有模板都走到”。
开 WP_DEBUG，逐个模板人工过：首页、单篇、归档、搜索、404、关于页。每个模板都要看到实际渲染，不能只看“没报错”。PHP 的 notice 和 warning 在生产环境通常被关掉，但它们是潜在问题的信号，本地必须开着。
然后是按需加载的逐项触发。我的主题里公式渲染、图表渲染、代码高亮这三个库是按需加载的，只有正文正则命中时才 enqueue。所以必须分别打开一篇含公式的文章、一篇含图表的、一篇含代码块的，确认每个库都在该加载的时候加载、不该加载的时候不加载。这一步如果偷懒，到了生产环境你不会知道某个库是不是在所有页面都多余地加载着，直到性能分掉下来才回头查。
有两个风险点是这个阶段抓出来的。
第一个，首页报头里用了服务端渲染的日期令牌。这意味着如果 HTML 被缓存 600 秒，页面上显示的日期会冻结在缓存生成的那个时刻，最坏情况差 10 分钟。处置是接受这个陈旧度，因为日期报头不是实时信息，10 分钟的偏差不影响任何人。但这个决策必须在本地做，不能到生产环境上线之后才发现日期不动了。
第二个，主题里有几个 pattern 引用了第三方域名上的图片，比如徽章。生产环境如果启用这些 pattern，就破坏了“零外部请求”这条原则，第三方域名挂了页面就慢。处置是清点站点实际用到哪些 pattern，没用的不启用，要用的考虑图片本地化。
这两个风险点如果在本地阶段没发现，到了生产环境就变成“为什么首页日期不对”和“为什么页面在等一个不认识的域名”这两类现场故障。本地验证的价值就是在这它们变成故障之前抓出来。
阶段一：换前基线，三到五天，三个视角
换主题之前必须在旧主题在产的时候采集基线。没有基线，换完之后的数字就没有可比性，你不知道“好”是真好还是只是不坏。
基线采三到五天，每天用同样的页面、同样的工具、同样的网络条件跑一次。判定标准我定的是正负 30% 以内算正常波动，不做过度归因。
采集必须分三个视角，不能混。
业务侧看的是流量层面：每小时请求量、各种拦截码的计数、封禁数。这些数字是你的站“正常长什么样”的基准画像。换主题之后路径和资源全变了，404 是这类变更里最容易放大的一条风险线，有基线才知道换完之后的 404 是正常新增还是异常激增。
服务器侧看的是机器本身：负载、内存、数据库慢查询、缓存命中率。换主题不应该影响这些，但如果新主题的资源加载方式不同，PHP worker 的消耗模式可能变。这一组数字是“机器有没有被新主题搞累”的参照。
CDN 侧看的是边缘命中率和回源量。换主题必须清缓存，清完之后命中率会掉，然后回升。有基线才知道回升到什么程度算正常。
表头必须写清采集时段和网络环境。同样的工具在早上跑和晚上跑，数字可以差 30%，不记条件就没有可比性。这条我定成铁律：基线表不写采集条件的，视为无效。
这一步还有一个测速方法上的坑，上一篇讲过但值得在这里再说一遍：源站直连视角在外面根本量不到。外部直连源站地址会被 WAF 挡成 403，要拿 PHP 的真实渲染耗时只能到服务器本机侧量。这意味着“边缘视角”和“源站视角”天生是两套数据、两台机器、两个采集条件，不能混在一张表里比。
阶段二：上线前检查清单，每一条都是踩过才加的
检查清单不是拍脑袋写的，每一条都是某个“差点出事”或“已经出事”之后加的。
先读服务器的安全运维文档。变更纪律是先读后改，因为生产环境上有别人或过去的自己留下的配置和约束，不读就改可能踩到不相关的红线。
备份要做三层：数据库全库导出、旧主题目录打包、记下当前激活的主题名。回滚不是“把新主题修好”，是“把旧主题重新激活加全量清缓存”。没有旧主题的完整备份，回滚就没有落点。
CDN 缓存规则要确认一件事：新主题新增的静态资源扩展名是否被已有的静态缓存规则覆盖。我的新主题自托管 woff2 字体，旧主题没有这个扩展名，所以必须确认缓存规则覆盖了 woff2，否则字体文件不进缓存，每次请求都回源。
WAF 适配要预演一件事：新主题的资源路径会不会触发 WAF 的 404 扫描封禁规则。主题换掉之后所有资源路径都变了，如果扫描器大量碰到 404，可能触发自动封禁。这个坑必须在上线前用预演发现，不能等上线后用真实流量撞。
最后一步是 wp-admin 的“实时预览”。WordPress 有一个不激活就能预览主题的功能，用它把首页和单篇过一遍。这不是验证，是最后一眼确认没有明显的渲染损坏。
阶段三：切换执行，选低峰，按顺序，不跳步
切换选在低峰时段。我的操作顺序是备份、激活、全量清缓存、逐页验证、缓存重建确认、运维文档记账。每一步做完再做下一步，不跳。
全量清缓存必须在激活之后立刻做。旧主题的页面缓存如果不清，新主题已经激活但访客看到的还是旧页面，混排是最糟糕的情况，比“整个站挂了”还难诊断。
逐页验证的清单和本地验证时一样，但多了两个维度：feed 和站点地图必须确认格式没变，登录页必须确认能正常加载。每个页面都应该是 200，不是 200 的要当场定位。浏览器开发者工具同时打开，确认字体加载成功、没有 404 资源、没有外部请求。
回滚条件我提前写死了四条：关键模板 5xx 或白屏、字体样式批量 404、误封激增、三十分钟内定位不了渲染损坏的原因。任何一条命中就回滚，不临场讨论。临场讨论的意思是你在压力下做判断，而压力下的判断质量是打折扣的。写死条件就是让回滚这个决策不需要判断力，只需要执行力。
回滚动作本身也写死了：重新激活旧主题、全量清缓存、缓存复核、运维文档记账。四个步骤，不需要思考，只需要执行。
阶段四：换后监测，前三天最紧，然后慢慢松
前三天每天采一次同参数快照，重点盯 404 计数。主题换掉之后资源和路径全变了，404 是这类变更里最容易放大的一条风险线。新主题资源如果 404，被扫描器盯上会放大；如果同时触发了 WAF 的 404 扫描封禁规则，可能变成误封。所以 404 计数是这一阶段的核心指标，不是性能分。
缓存命中每天验一次。首页和字体文件必须命中，单篇文章页一开始可能 MISS（每次回源），这是预期的，但要确认它不是因为缓存规则没配对。
前两周每周做一次更深度的检查：主题版本和模板文件完整性（用 wp-admin 的主题文件编辑器抽查几个关键文件，确认没有被意外修改）、第三方性能分复测、搜索引擎收录快照抽查渲染是否正常。最后一条是因为换主题会影响 HTML 结构，搜索引擎需要重新爬一遍才能适应新的 DOM。
稳态之后，把换后实测数值更新为新的基线，然后并入现有的例行巡检节奏，不再有额外动作。
两个坑
第一个坑在阶段三。上传主题安装包的时候，站上一个对象存储同步插件被上传钩子唤醒了。它的配置还是空的，直接 fatal。这件事的教训不是“记得配置插件”，是“你改的是主题，但被牵连的东西不在你的改动范围里”。阶段二的检查清单里从此多了一条：所有带上传钩子的插件，配置必须提前备好，不能留空配置激活。
第二个坑更早，在阶段一和阶段二之间。换主题之前我调了一次 WAF 规则，为了看新规则的行为对不对，切到了观察模式。然后忘了关，开了两天半。那两天半里来了三起洪水，WAF 在观察模式下全部放行，源站被打穿。这个坑的教训是：观察模式不是安全状态，是裸奔状态。切完规则必须当天回来看，确认完就切回拦截。换主题的窗口前后尤其不能再开观察模式，因为那几天每一项变更都需要 WAF 在拦截状态兜底。
这套流程里什么没做
本地验证只覆盖了“模板能渲染、资源能加载”这一层。没有在本地跑真实流量压测，因为本地环境的 PHP 版本、数据库数据量、缓存行为都和生产不同，压测结果的参考价值有限。真实的性能验证完全依赖阶段一的基线对照和阶段四的监测。
阶段一的基线采集窗口是三到五天，但如果在这个窗口里恰好遇到了异常流量事件（比如一次洪水），基线会被污染。我没有做“剔除异常天”的标准化处理，只是凭经验判断哪些天的数据应该排除。这在流量较小的站上够用，规模一大就需要更严格的统计方法。
阶段四的搜索引擎收录适应期观察只做了两周。实际上 WordPress 换主题之后搜索引擎可能需要更长时间才能完全适应新的 HTML 结构，两周只是“看起来正常了”，不是“已经稳定了”。
收尾
激活那一秒做完之后，真正的安全感来自四样东西：旧主题的完整备份、一份写清采集条件的换前基线、四条写死的回滚条件、前三天每天一次的同参数快照。这四样东西缺任何一样，出事的时候你就得临场判断，而临场判断的质量是打折扣的。
主题现在是 0.10.13，系列写到这儿，从主题设计到性能到运维到防护链到变更管理，五个角度走完了。如果这篇有第六篇续篇，大概该写这套流程本身怎么固化成脚本和检查清单，让它不依赖我的记忆。但那件事我还没做，做了再写。
发表回复