安全公告为什么要提前公布修复时间，预告窗口期该做哪几件事
安全公告为什么要提前公布修复时间？直接的回答是：让一批修复在同一时刻落地、让使用方有时间准备，而不是提前把未修补的站点暴露出去。这个判断可以从 Drupal 官方的一条预告读出来：针对 Webform 项目一个被评为 critical 的问题，官方预告修复版本将在 2026 年 9 月 23 日 17:00 至 21:00 UTC 之间发布，给出的理由是该模块被相当大比例的站点使用，并且同一次发布会带来数量可观的多条公告。集中发布的意思很明确——在同一个时间窗内把多数修复一起交付，避免”逐个公告、逐个暴露”。
为什么宁可可预告
第一，集中发布能压缩总暴露时长。分散发布时，每一批修复从公告到被站点采纳都有滞后，多批叠加起来，整体暴露窗口被拉长；一次集中交付只留一个窗口。
第二，使用方需要准备。跨版本迁移、数据脚本、模板兼容都不是当天能完成的事，没有预告就只能带伤升级。
第三，公告数量本身是信息。官方明确说这次会带出相当数量的修复，站方就能判断这是一次常规补丁还是一个成体系的问题，从而决定要不要安排专人值守。
预告到发布之间会发生什么
这段时间攻防双方都在准备。防守方清点模块、备份数据、安排测试；另一方面，公告里披露的模块名与严重度对攻击方同样是线索——虽然还没有补丁细节，但”哪一类问题、在哪个模块”已经缩小了探测范围。这决定了窗口期的动作方向：不是等，而是收敛。
| 时段 | 主要任务 | 容易犯的错 |
|---|---|---|
| 预告发布后当天 | 确认自己是否用到该模块，登记负责人 | 只转发公告不落地 |
| 预告到发布前 | 收敛写入面、完成备份、准备预发环境 | 提前手工替换核心文件 |
| 发布窗口内 | 升级、验证、观察异常 | 只看后台成功提示 |
| 发布后 24 小时 | 复查日志、轮换凭证、补齐遗漏站点 | 升级完就收工 |
窗口期动作清单
清点受影响模块。把公告里的模块名与自己的实际安装对照，多站点环境要逐站核对，不能假定所有站都用同一套配置。
收敛不必要的面。暂时关闭评论、表单、注册这类外部写入入口，或者收紧到已登录用户，是最直接的降风险动作。内容侧还有可用的一层：敏感词过滤与内容审核可以在升级前把外部提交内容的处理档位提高，减少异常内容直接进入正文的机会。
安排升级与验证。优先在预发环境跑一次，验证三处：后台登录、列表与筛选、写入接口。AnQiCMS（安企CMS）在 v3.6.6 里修掉的正是列表排序参数与站点切换登录凭证这两类问题，两处都属于”升级后必须专门验证”的位置，因为它们分别落在读取路径和认证路径上。
准备回退点。升级前完成数据与静态文件的备份，并确认能真的恢复；无法回退的升级应当推迟，而不是靠运气。
发布后 24 小时做什么
一是复查访问日志，看窗口期内是否有针对该模块的异常请求，这决定了凭证轮换的范围。二是补齐遗漏站点，多品牌与多语言并行的环境最容易漏掉测试站与旧活动页所在的实例。三是把这次的时间线记录归档：公告时间、完成升级时间、验证结果，下一次同类窗口期就有可参考的内部数据。
常见问题
问：预告之后能不能提前自己打补丁？ 答：不建议手工改核心文件。补丁细节未公开时自行修改，容易和官方修复冲突，且无法验证是否真的堵住了问题。
问：严重度是 critical 就一定要停站升级吗？ 答：取决于该模块是否在你的站点上实际启用。未启用就不需要停服；已启用且涉及外部写入，缩短窗口比保全可用性更重要。
问：没有预发环境怎么办？ 答：先做备份再升级，把验证动作压缩到登录、读取、写入三项，出问题立刻回退。这比在没有回退点的情况下直接升级安全。