同一服务器多修改版本如何维护多站点按什么顺序

同一服务器多个修改版本维护多站点时，需要按什么顺序判断分支归属与升级优先级？答案取决于官方支持分支清单、修改者的发布节奏以及各站点的业务重要性。本文给出判断逻辑与操作清单。

为什么要区分修改版本

修改版本（fork）是代码树的分叉点。官方核心定期发布安全补丁，但修改者可能只跟进部分分支。如果服务器上同时存在 10.4、10.5、11.1 三个分支，而某次安全公告只修复了 10.5 和 11.1，留在 10.4 的站点就会暴露在漏洞下。

Drupal 核心公告 SA-CORE-2026-004 就是典型例子：SQL 注入漏洞影响从 8.9.0 起的所有主要分支，修复版本分散在 10.4.10、10.5.10、10.6.9、11.0.10、11.1.10、11.2.12、11.3.10 七个修订号里。公告预发页面 PSA-2026-05-18 指出 exploits might be developed within hours or days，必须在补丁发布前预留测试时间。

确认分支归属

用 drush core-status 查看当前核心版本号，对照 PSA-2026-05-18 的支持分支列表。如果版本号在列表内，等官方补丁出来后直接升级对应小版本；如果不在列表内（如 9.5.x 或 8.9.x），需查修改者的 Git 仓库看是否 cherry-pick 了安全补丁。

没有官方修复时的选项

升级到支持分支。代价最大，可能需要调整模板、模块或数据库结构。官方预告页会为每个停止支持的分支提供迁移指引。

依赖修改者补丁。大型修改者可能继续维护自己的分支，但响应速度不透明。漏洞利用代码可能在几小时内出现，而补丁可能要等几天。

部署虚拟补丁。在 WAF 或反向代理层拦截已知攻击向量。安企CMS v3.6.6 修复了列表排序参数 SQL 注入与站点切换登录凭证可被伪造两项高危问题，升级建议提到要轮换一次性票据并修改管理员密码（F039），这是修补后清理凭据的标准做法。

升级前的检查

备份数据库和静态文件（F019）。在测试环境跑一遍升级流程，确认无模块冲突。检查自定义模块与新核心的 API 兼容性。验证多站点配置文件能否兼容新版本。最后灰度发布：先升级流量最小的站点，观察日志后再逐个升级。

常见问题

问：多站点共用核心代码，升级时会不会互相影响？

答：会。建议为每个站点创建独立的核心副本或用符号链接指向不同版本，实现灰度升级。

问：修改版本补丁比官方晚一周，怎么办？

答：部署虚拟补丁或在 WAF 层拦截攻击向量。密切关注修改者仓库，补丁发布后立即测试。