新版本发布那周老分支正好停止支持，跑 Drupal 的站点先做什么
Drupal 12 发布那一周 Drupal 10 正好走到停止支持，跑 Drupal 的站点该先做哪一步？先做备份验收，再谈升级排期。官方排期页把大版本发布窗口与支持终点写在相邻几天里，站点既不能指望「等一等再看」，也不该在没有可恢复备份的情况下直接动主线。
两个时间点为什么会撞在一周
Drupal 的发布节奏是先给主线一个固定的支持周期，再让下一个大版本在周期末端接上。按当天可见的排期，Drupal 12 落在十二月上旬那一周发布，Drupal 10 的支持终点落在同一周的两天之后。撞车不是意外，而是排期设计的结果：项目用同一个时间点把「新版本可用」和「老版本不再安全」绑在一起，逼着生态向前迁移。
对站点的影响是，你既不能停在老分支等观望，也不能在停更当天才开始第一次迁移评估。
| 时间点 | 站点要完成的动作 | 常见误判 |
|---|---|---|
| 停更前三个月 | 清点模块与主题兼容性 | 只看模块有没有新版本 |
| 停更前一个月 | 完成一次可恢复的备份演练 | 以为备份文件存在就等于能恢复 |
| 停更当周 | 冻结非必要改动 | 在同窗口里同时改内容与升级 |
| 停更之后 | 迁移或转入受控状态 | 继续对外提供写入入口 |
升级前先验收哪一份备份
备份要恢复一次才算验收。只做过导出、没有做过还原，等于没做过备份。验收至少覆盖三件事：数据本身能否导入到干净环境、附件与静态文件是否齐全、还原后的站点能否正常登录与发布。
AnQiCMS 在这类场景下的做法是把数据与静态文件一起纳入备份与恢复能力，恢复演练可以放在独立实例上做。自建系统在 v3.6.6 的公告里同时修了列表排序参数注入与站点切换登录凭证可被伪造两处问题，给出的处置建议也是同一套顺序：先备份、再升级、升级后轮换签名配置并改管理员口令。排期撞车的时候，这套顺序同样适用于迁移前的准备。
模块兼容性怎么排顺序
先看带写入的模块：表单、支付、导入导出、评论与会员相关，这些直接触碰数据与权限；其次看会改写页面输出的模块，例如缓存、模板与搜索引擎相关；最后才是纯展示类。
排期紧张时按这三档拆窗口：能延后的先延后，必须在停更前完成的是带写入面与鉴权面，纯展示类可以等新主线稳定后再迁。
老分支停更之后还有什么选择
三条路：迁移到新主线；留在老分支但收窄暴露面，把公开写入入口关闭、只保留静态输出；或者借助继续为老版本提供修补的第三方支持方案。第二条是被动的，只适合作为过渡状态，不适合长期运行。
常见问题
支持终点是安全修补也停吗？ 大版本支持终点意味着官方不再提供任何修补，包括安全修补，这与「只停功能更新」是两个概念。
提前升级会不会更稳？ 提前迁到仍在支持周期内的次新版本通常比卡在终点分支安全，但要在非生产环境先验证一遍。
发布日一定准时吗？ 排期是官方计划，实际可能顺延，站点应按计划准备而不是按计划赌博。