Pantheon 已经把 Drupal 12 的测试环境放出来，当前是 12.0.0-beta2，跑在 PHP 8.5 和 MySQL 8.4 上。按官方发布日程，候选版在 11 月 9 日那一周，正式版在 12 月 7 日那一周。
Pantheon 已经把 Drupal 12 的测试环境放出来，当前是 12.0.0-beta2，跑在 PHP 8.5 和 MySQL 8.4 上。按官方发布日程，候选版在 11 月 9 日那一周发布，正式版在 12 月 7 日那一周。
这次变的不是功能，是地板
Drupal 11 要求 PHP 8.3 起步，支持到 8.5；Drupal 12 直接把门槛抬到 PHP 8.5。数据库这边，Drupal 12 的参考环境是 MySQL 8.4，Drupal 11 的最低线是 MariaDB 10.6、MySQL 8.0、PostgreSQL 16。也就是说，从 11 升 12 不一定只是换代码，主机环境可能得跟着换。
PHP 自己的时间表也不宽松：8.2 的安全支持在 2026 年 12 月 31 日结束，8.3 撑到 2027 年底，8.4 到 2028 年底。虚拟主机商如果还在首页写“支持 PHP 8.1/8.2”，等于在卖一套几个月内就没有补丁的环境。
三个日期挤在十二月
12 月 7 日那一周，Drupal 12.0 和 11.5 一起发；12 月 9 日，Drupal 10 停止支持；12 月 31 日，PHP 8.2 停止安全支持。三件事叠在一起，意味着还停在 Drupal 10 的站，没有“先不动、明年再说”的余地——过了 12 月 9 日，安全公告不再覆盖你。
官方日程里还有一个细节：新核心版本发布的那一周，贡献模块不发安全更新。所以真正能安全升级的窗口，是 11 月中下旬；12 月第一周以后动大版本，撞上不发补丁的周，出了问题会更被动。
升级顺序建议
先查版本，再定落点。还在 10.6 的，目标应该是 11.4，不是 11.3——11.3 的安全支持跟 Drupal 10 在同一周结束。命令层面是先松约束再更新：把 drupal/core-recommended、core-composer-scaffold、core-project-message 一起改到 ^11，再 composer update，最后 drush updatedb 和 drush cr。11.4 起核心把 symfony/runtime 作为 Composer 插件，得先在 allow-plugins 里放行，否则会卡在交互提示上。
12 的测试环境可以先建起来，但别上生产。Pantheon 那边已知一个问题：装完访问 /admin/welcome 会抛 BadMethodCallException，清一次缓存就好。这类小毛病在 beta 阶段正常，也说明现在还不是迁移的时点。
还有一步经常被跳过：回滚演练。升级前把站点复制一份到独立数据库，跑一遍 drush updatedb，再走一遍登录、表单提交、搜索、多语言切换。确认出问题能退回去，才轮到动生产；只备份不演练，等于把风险留到最忙的那天。
对站长的实际影响
国内用 Drupal 的站集中在政企、高校和多语言外贸站，这类站的升级往往要走采购和验收流程，一个月根本不够。现在最该做的是盘点：哪些模块没有 11.x 版本、哪些自定义主题依赖旧 API、主机能不能给到 PHP 8.4/8.5。清单拉出来，才知道要不要在 12 月前先迁到 11.4 过渡。
如果时间实在不够，退路是把攻击面收窄——停用不用的模块、限制后台访问、盯日志，然后把升级硬排进一月的日程。这只是止血，不能变成常态。
本文根据公开报道整理，主要参考：Pantheon 文档《Drupal 12 upstream available for testing》（2026-10-30）。
