Drupal 10 生命周期终止：升级实施方案

摘要：Drupal 10将于2026年12月9日停止支持。本文包含关键时间节点、常见升级阻碍，以及一套切实可行的12周升级至Drupal 11的执行方案。

作者：成都长风云Drupal开发团队

目录

1. Drupal生命周期终止时间：需要重点关注哪些内容
2. 应当升级到Drupal 11，还是等待Drupal 12
3. 第一步：评估工作量前先运行升级状态检测模块
4. Drupal升级的三类常见阻碍
5. 分四阶段完成，为期一个季度的Drupal升级方案
6. 升级期间保护网站搜索可见性
7. 企业应当如何为Drupal升级做预算规划
8. Drupal扩展支持包含哪些服务，成本如何
9. 政府项目团队：审批流程需要与开发排期同步
10. 需要尽早明确的Drupal升级相关问题
11. 从就绪度评估开始启动项目

升级工作表面看起来简单，直到有人问到表单业务所依赖的某个模块。模块目前还能运行，但没人记得是谁安装的，而且它已经好几年没有新版本发布。

这就是Drupal升级会演变成项目规划难题的根源。

Drupal 10将于2026年12月9日正式终止生命周期。Drupal 10.6是最后一个次要版本，截止该日期之后官方将不再发布任何Drupal 10版本更新。Drupal官方发布计划确认了该时间。

对开发人员来说，升级涉及依赖包、自定义代码与基础设施。对于使用Drupal的企业，还涉及预算、版本发布审批、编辑工作流，并且要保证变更全过程业务服务可用。

目标明确的升级项目可以在一个季度内完成。最开始两周就需要判断这个时间周期对当前站点是否现实。后续工作重点是尽早解决阻碍、预留充足测试时间，上线部署时预留应对意外故障的回滚空间。本文就提供这样一套可落地的实施框架。

Drupal生命周期终止时间：需要重点关注哪些内容

仅看主版本号，无法判断Drupal站点是否还能获得安全维护，不同次要版本有各自的支持周期。

时间参考官方内核发布计划与Drupal11发布文档，后续发布周期存在变更可能性。

站点不会在生命周期终止的那一刻直接停止运行；风险在于该版本不再收到官方维护和安全补丁。网站表面运行一切正常，但维护风险会持续累积，后期修复难度越来越高。

应当升级到Drupal 11，还是等待Drupal 12

对于现有Drupal10站点，请立刻规划迁移到Drupal11。

Drupal官方支持的升级路径必须顺序迭代主版本：

Drupal 10 → Drupal 11 → Drupal 12

标准升级流程不允许跨主版本直接升级。新版本会移除旧版本数据库和配置升级程序。官方文档说明，升级Drupal12必须先升级至Drupal11.3或更高版本。

针对2026年秋季的升级项目，Drupal11.4最新补丁版本是稳妥目标。它拥有稳定可测试的正式版本，安全维护周期也覆盖12月之后。

Drupal12评估作为独立维护事项排期，它的发布并不会让已经受支持的Drupal11变得过时。

明确项目边界：网站改版、内容重构、新增客户门户等属于额外需求，会带来额外需求评审和验收工作。将这些工作单独排期，保证版本升级工作可控。

第一步：评估工作量前先运行升级状态检测模块

靠谱的升级评估，必须基于你当前真实运行的站点。

在Drupal10的开发或预发布环境，安装并运行Upgrade Status（升级状态）模块。该模块会检测环境要求、贡献模块兼容情况、代码对下一主版本的适配程度。

务必在内核升级之前执行评估。部分检测依赖Drupal10还保留、但Drupal11已经移除的废弃API。请阅读该模块官方安装使用文档，满足其依赖条件。

将扫描结果整理成可执行清单：

为每一个阻碍项指定负责人与截止时间。清单同时写明业务影响。“模块不兼容”对项目管理者信息太少；写成“活动报名表单依赖一个没有兼容版本的模块”，才方便管理层理解并决策。

扫描结果仅作为起点，它无法验证财务集成接口返回数据正确性，也不能确认编辑审批工作流是否正常。

Drupal升级的三类常见阻碍

1. 贡献模块缺少受支持的升级路径

模块可能没有Drupal11版本；或者依赖其他不兼容的包；或者虽然标注支持Drupal11，但你正在使用的特定功能还存在未修复Bug。

不能只看模块的兼容性声明，还要查看维护活跃度、更新日志、安全通告，以及站点已经打的补丁。

然后选择处理方案：

• 更新：存在维护良好的兼容版本时直接更新
• 替换：寻找其他可以满足同等业务需求的替代方案
• 移除：该业务功能已经不再使用
• 出资推动适配：该模块是核心依赖，且适配改造具备可行性

举例：落地页上老旧轮播模块，替换成本很低；但控制报名资格校验的模块，则需要深度调研。

卸载模块前，确认该模块的数据、配置归属关系。卸载模块可能会破坏已存储内容与系统设置。

2. 自定义代码调用已经被移除的API

自定义模块、主题可能使用Drupal10标记废弃、Drupal11彻底移除的API。官方推荐使用Upgrade Status与Drupal Rector工具识别、修复这类代码变更。

自动化修复完成后，必须人工复核并测试业务行为。同时关注内核已经移除的功能：图书、论坛、统计、Tour向导组件。如业务依赖，要在升级之前切换到对应的贡献模块替代方案。官方Drupal10升级指南有相关准备步骤。

重点关注系统集成场景：首页可以正常打开，但定时导入任务可能在夜间静默失败。

审查清单包含自定义鉴权、外部API调用、队列、定时任务、权限修改相关全部代码。

3. PHP与托管环境要求

Drupal11要求PHP8.3及以上版本，版本必须匹配目标Drupal版本支持列表。PHP8.4同时被Drupal10.6与Drupal11.4支持，如果依赖包允许，可以作为过渡版本。查阅官方PHP兼容矩阵。

同步评估数据库、PHP扩展、Composer工具链、部署脚本。

全部环境都要核对：开发者本地、自动构建流水线、预发布、生产环境。本地升级成功，不代表生产PHP版本或扩展满足条件。

尽早把云服务商纳入项目范围，基础设施变更本身也需要排期与审批。

分四阶段完成，为期一个季度的Drupal升级方案

下面12周框架，前提是专职交付团队、目标聚焦版本升级。完成初步评估后再确认时间表是否适用。

假设项目9月14日启动，目标生产部署窗口为11月16‑20日。在官方终止生命周期之前，预留后续监控与应急缓冲时间。

大型多站点集群、复杂发行版、大量无人维护的定制代码，需要更多人力或拉长周期。

阶段一：站点评估与确定项目范围 — 第1‑2周

运行升级状态模块，梳理依赖、补丁清单，完成托管环境评估。

如果生产还在运行Drupal10.5或者更早版本，在做大版本升级之前优先完成Drupal10.6稳定版的测试升级。

梳理站点核心业务流程，例如申请表单提交、下单购买、文档库检索、多语言内容发布。

明确项目各方责任归属：

评估结束前完成棘手依赖项的决策。如果需要等待上游模块新版本，要设置复查时间，并且准备备选方案。

阶段完成标准：项目范围、升级阻碍、责任人、工作量评估、计划发布日期全部确认。

阶段二：解决兼容性问题 — 第3‑6周

更新有兼容版本的贡献模块；重构自定义代码；复核补丁；处理内核移除功能带来的依赖问题。

准备目标运行环境，在站点副本上完成第一次Drupal11完整升级。

所有修改做到便于代码评审；记录每一处补丁、依赖调整的原因；确认原有问题彻底解决之后，再删除临时兼容方案。

全新构建预发布环境，验证升级过程具备可复现性，不能只依赖某个开发人员本机环境跑通。

本阶段同步暴露范围风险，如果核心模块需要大规模替换改造，在还有调整余地的时候更新项目计划。

阶段完成标准：预发布环境Drupal11正常运行，全部兼容性阻碍都经过测试并解决。

阶段三：业务流程测试与上线演练 — 第7‑9周

完整测试全业务链路，包括页面交互之后的后台逻辑。表单提交成功，不仅页面提示成功，还要确认数据入库、通知下发、下游系统正确接收。

覆盖站点相关业务场景：

• 权限访问：登录、单点登录、角色权限、受保护内容
• 内容发布：编辑、预览、审核、多语言翻译、定时发布
• 表单：校验、附件上传、提交回执、下游业务流转
• 电商业务：结算、支付回调、订单通知
• 系统集成：API接口、导入导出、队列任务、定时任务
• 页面展示：移动端布局、关键模板、交互组件
• 无障碍访问：键盘导航、焦点状态、标签、错误提示

邀请内容编辑、业务负责人参与测试，他们熟悉日常操作与边界场景，自动化测试无法全部覆盖。

使用一份近期生产数据副本，完整演练生产发布流程。统计数据库更新耗时，确认需要的维护窗口。测试代码‑数据库‑文件的完整回滚恢复流程。如果网站有订单、报名等实时业务，要定义回滚发生时如何处理新增业务数据。

阶段完成标准：业务验收通过；上线步骤完整演练；故障回滚方案经过验证。

阶段四：部署上线、监控与交接 — 第10‑12周

计划在第10周执行上线。发布前确认备份策略、维护时间窗口、业务/表单流量管控、上线与否的决策人。

上线完成立刻核验核心业务流程；持续监控应用报错、任务失败、表单投递、接口调用、站点性能。

上线稳定期保持开发团队待命，部分问题只会在定时任务、特定编辑操作触发之后显现。

完成维护交接文档，内容包含：

• 当前部署版本，已知非严重问题清单
• 安全更新维护责任归属
• 监控与故障对接联系人
• 下一次依赖包复审计划
• 下一次Drupal次要版本评估计划

阶段完成标准：生产环境运行稳定，业务验收确认，后续维护责任明确分配。

升级期间保护网站搜索可见性

升级计划中必须包含SEO校验，尤其模块、主题修改会影响页面渲染输出时。实施升级前先建立基准快照，记录重要URL、重定向规则、页面标题、规范标签、索引规则、站点地图输出。

升级完成之后核对：

• 核心URL返回预期页面与HTTP状态码
• 重定向跳转目标正确
• canonical规范标签指向生产域名
• 预发布环境noindex禁止索引配置不要被带到生产
• XML站点地图正常输出，包含全部目标页面
• 页面元数据、结构化数据保留完整
• 统计代码、隐私合规埋点正常工作

使用爬虫对比升级前后页面差异，区分哪些变更属于业务预期调整，哪些是异常故障（例如大量页面无法访问需要立刻处理）。指定专人负责该部分校验，否则容易落在开发、市场、内容团队职责缝隙。

企业应当如何为Drupal升级做预算规划

合理预算必须基于评估阶段发现的实际工作量。预算拆分：前期调研评估、贡献模块改造、自定义开发、基础设施、测试、上线部署、上线后稳定保障。

要求服务商报价写明前提假设。报价默认所有模块都有兼容版本，但是实际审计发现关键模块无人维护，这个报价就需要重新核算。

同时梳理企业内部需要投入的资源：内容编辑需要投入验收测试时间；运维团队准备环境；业务负责人要及时参与需求决策。

多站点集群，评估共享平台部分，同时梳理各个站点差异化配置与集成；公共代码可以减少重复工作量，但差异化业务仍然需要逐个验证。

完成评估，消除主要不确定性之后再正式审批预算；预留对应风险的应急资金。

Drupal扩展支持包含哪些服务，成本如何

扩展安全支持属于商业合同服务。Drupal协会公开的扩展安全支持计划仅针对Drupal7，并没有同等官方项目覆盖Drupal10。

如果你计划采购扩展支持，务必拿到书面文档确认版本覆盖范围与价格。需要确认合同关键点：

总费用可能包含补丁授权、实施部署、测试、Drupal之外依赖组件的维护。横向对比服务商报价时，保证评估范围一致。普通月度维护包可能只负责安装已有补丁，并不负责为停止维护的软件开发安全修复。签约前分清权责。如果选择购买扩展支持，必须绑定明确的升级截止时间和审批预算。

政府项目团队：审批流程需要与开发排期同步

Drupal大量用于公共机构内容发布，例如美国EPA WebCMS、澳大利亚GovCMS政府内容平台。这些案例说明升级规划不止是写代码。

政务系统上线往往涉及采购流程、无障碍评审、安全测评、业务主管审批。相关评审工作要在项目最开始两周就纳入排期，开发实施过程中预留评审人员时间。

验收标准聚焦于对外提供的业务服务：居民可正常提交申请、编辑可以发布紧急公告、工作人员可以访问业务信息。

托管平台项目，厘清服务商与机构各自职责：谁升级平台内核，谁校验定制功能，谁做最终上线审批。可以查阅Drupal政府行业案例获取更多参考。

需要尽早明确的Drupal升级相关问题

Drupal10升级到Drupal11是否等于站点全部重构？

官方升级路径支持现有站点平滑迁移。是否需要大规模重写取决于你的自定义代码、第三方依赖、业务需求。通过前期评估确定实际改造范围，官方升级指南描述标准流程。

能不能保证12周一定完成升级？

完成调研评估之后再确认时间表。12周只是规划框架；实际工期受核心依赖、基础设施约束、评审人员排期影响。

是否必须一次性升级全部站点？

多站点共享平台，可以选择代表性站点作为试点，验证完整流程；再按照业务差异与服务优先级，分批升级剩余站点。

如果项目启动时间晚于计划怎么办？

评估工作不能简化，快速完成关键决策。可以对可并行任务增加人力，保障评审人员时间。如果存在延期风险，明确书面记录降级备选方案，但必须保留完整测试、回滚能力，保障可控上线。

从就绪度评估开始启动项目

项目第一个可交付物，是一份简短、可以直接用于决策的升级就绪评估报告。报告包含升级状态模块扫描结果、依赖模块处理方案、托管环境要求、测试范围、预估工作量、计划生产上线时间。每一个重大阻碍项，都分配负责人和下一步行动。

如果你需要评估与实施支持，可以参考Dynamosys的Drupal开发服务。沟通时带上当前Drupal版本、模块清单、托管环境信息、已知问题。把迫近的版本终止期限，转化成可排期、可申请预算、可落地交付的项目。越早发现棘手依赖，你就拥有越多的修复方案可选。