WordPress 7.2 正式版拟在 12 月 9 日发布，升级预演窗口该提前多久排？
大版本发布日期公布后，升级预演窗口该提前多久排？WordPress 官方开发博客已写明 7.2 的拟定最终发布日期是 2026 年 12 月 9 日（周三），Beta 1 排在 10 月 20 至 22 日、首个候选版 RC 1 排在 11 月 17 至 19 日。对站点来说，值钱的信息不是「12 月有大事」，而是日期已经确定——确定的日期意味着一切动作都可以倒排，不必在发布周临时应战。
确定日期带来的排期空间
从拟定发布日往前数：RC 1 到正式版之间有大约三周，Beta 1 到 RC 1 之间又有一线测试版本。一个有定制主题、表单、接口对接的站点，真正需要的时间往往不是「点一下更新」，而是把兼容性验证、回归测试、数据备份三段路走完。以 12 月 9 日为终点、提前六周左右启动预演比较稳妥：此时 RC 版本已经出现，问题面基本收敛，而留出的缓冲足以应对一次意外的回退重来。
倒排四步：清单、试装、备份、回退
第一步是清单：把站点当前依赖的扩展逐项列出，标记哪些已声明支持新版本、哪些还在观望，兼容风险主要藏在改了对内接口的版本里。第二步是试装：搭一套与生产同构的测试环境——用 Docker 镜像或宝塔面板部署的站点，复制一个同版本实例的成本很低，把候选版本先装到测试站，跑内容发布、表单提交、接口调用这几条主流程。第三步是备份：生产站升级前做一次含数据与静态文件的完整备份，确认恢复路径可用，而不是只留一个「看起来成功」的备份文件。第四步是回退预案：明确「升级失败回到哪一步、由谁操作、多久内完成」，写下来，别口头约定。
发布周当天不做什么
拟定发布日当周，多数团队会急着当天跟随，这段最该做的是克制：正式发布后的头几天是第三方兼容性问题集中暴露期，没有预演过的站点建议等一个小的维护版本落地再动；有预演过的，也避开业务高峰时段执行，升级完成后按清单逐项回归，而不是只看首页能不能打开。另外，升级前值得到官方在线体验站或演示环境先过一遍新版后台的操作路径——功能入口变了会让当天的值班同事手足无措，这类摩擦提前一小时演练就能消除。AnQiCMS 的在线体验站 demo 就是这种用法：正式升级前先在体验环境把后台路径走熟，再回自己站点操作。
常见问题
小站点没有测试环境，预演还有意义吗？ 有，成本更低的做法：升级前完整备份，把「发布内容、提交表单、调用接口」三条主流程写在纸上，升级后逐条打钩。
拟定日期会不会跳票？ 会，开源项目的发布日程常因关键问题顺延，所以预演按「最晚不迟于 RC 出现后启动」排，比押住正式日期更稳。
能不能干脆不跟大版本？ 可以选择不跟，但要接受跟随成本后移：留守旧线意味着后续安全维护节奏由不得自己，建议每半年重估一次。