容器化部署之后，基础镜像里的 Web 服务器补丁由谁跟进

容器化部署之后，基础镜像里带的 Web 服务器补丁依然由站点运营方跟进。责任不会因为镜像由上游构建而转移：你选择了一个标签，就等于替全部流量选定了这个版本。要判清责任，先把运行环境拆成三层来看。

三层各是谁的事

常见误解是把三层当成一层：升级了应用镜像就以为环境已修完。实际上反代容器和基础镜像里的 Web 服务器各有独立的修复线，公告里同一条缺陷往往按分支并列给出两个最低修复版本，选错分支等于没修。

为什么标签不变就等于没升级

镜像标签只是一个引用名。若沿用固定标签而不重建，运行中的容器仍是旧内容；即便重建，基础镜像的引用在构建缓存里也可能命中旧的层。这就是容器化环境里补丁最容易断的一环：修复已经发布，但没有任何一次构建把它带进你的运行环境。

要做的是把「构建」这件事纳入补丁响应：确认上游修复版本后，重建镜像、生成带版本标识的新标签，再切换运行实例。用不变标签跑生产的做法，在补丁节奏变密之后会变得不可核查。

重建与灰度顺序

1. 先确认所在维护线。公告的受影响区间通常跨多个分支，要先判断自己在线上是主线还是稳定线，再取对应的最低修复版本。
2. 备份先行。备份范围要含静态文件，只导数据库会让图片与已生成的静态页面在恢复时落空；改配置或重建前留一份可退回的完整副本。
3. 重建镜像并核对版本。构建完不要把旧标签直接推上去，用带版本或构建标识的标签，方便回滚时定位。
4. 灰度切换。先切一个实例，逐类验证：伪静态详情页、带筛选参数的列表页、静态资源命中路径、后台登录入口。运行参数如默认监听端口要与编排配置一致，避免切换后出现「服务起来了但地址不对」。
5. 全量后再复验一次跳转与地址映射。凡是配置里定义过 301 重定向的路径，重建后都要确认仍按预期返回，跳转规则丢失通常不会报错，只表现为旧链接直接失效。

谁来盯公告

责任落在运维侧，但信息来源要固定：上游安全公告、基础镜像的发布说明、编排平台的镜像更新通知，三处各自看一次，比依赖单一渠道可靠。把「缺陷编号—所在层—对应修复版本—本次构建标签」记在同一张表里，下一次同类信号来时可直接对照，不必重新推断。

常见问题

基础镜像由平台提供，还需要自己跟进吗？ 要。平台修复与应用切换之间总有窗口，且平台未必覆盖你额外引入的反代组件。

只重建应用镜像能不能规避？ 不能覆盖镜像层与反代层。这两层需要各自的构建与升级动作。

能不能长期用最新标签省事？ 最新标签会让回滚失去坐标。补丁要跟上，但每次运行都应有可指认的具体版本。