补丁后旧进程仍加载漏洞库

补丁打完了，扫描还在报警，这种情况在运维群里被吐槽过不止一次。最后的答案往往很朴素：机器上那个老进程压根没重启过。

升级动作改的是磁盘上的库文件。进程启动时会把需要的动态库加载进内存，之后一直用内存里那一份。包管理器把文件替换掉之后，老进程手里攥着的仍是旧的，操作系统一般只是把这个文件标记为已删除，句柄还挂在那里。磁盘上写着新版本，跑起来的还是老代码。

想看看到底哪些进程还在用旧库，有个很直接的检查方式：用 lsof 之类的工具去筛那些指向已删除 Brotli 解码库的句柄。输出里每一行，都代表一个仍在执行旧代码的进程。这个动作不需要碰业务，也不需要发任何请求，纯只读。

拿办公室打个比方可能更好理解：门禁系统换了新规则，卡也换了一批，但值夜班的保安还是照老规矩放人。制度改了，执行的人没换，门口那道口子就一直在。

容器环境还要多绕一层。镜像是自带一套副本的，宿主机上升级系统包管不到它，得确认构建产物重新打过了、新镜像真的滚动生效了。至于静态编译进二进制的情况更隐蔽，包管理器里根本查不到它的影子，只能靠二进制特征或者 SBOM 去比对。

所以判断一个资产是不是真的修好了，至少要对齐三层：磁盘上的包版本、内存里实际加载的库、以及进程有没有被重启替换。三层对不上，就是一个表面干净、实际还在跑旧代码的状态。

补丁上线之后，复测的顺序也建议照着这个思路走：先核对版本，再核对运行状态，然后重跑可达性对比请求，最后做业务回归和日志审计。任何一项不通过，就触发回滚。回滚靠的是变更之前准备好的快照和旧镜像标签，所以备份得提前做完并且验证过能恢复，而不是出事之后才想起来找。

补丁是个动作，重启和复测才是结果。很多人卡在中间那一步，以为动作做完事情就结束了。