多容器环境下运行时依赖盘点方法

容器化之后，最容易被误判的一件事，是把镜像 tag 当成运行时版本。同一个 tag 在不同时间拉取，指向的镜像内容可能已经不同；本地已经存在的旧镜像，也不会因为上游发布更新而自动变化。盘点多容器环境下的运行时依赖，起点应当是镜像 digest，而不是 tag。

分别记录镜像、容器与进程

盘点需要覆盖三层对象，缺一层就会留下盲区。镜像层记录每个业务镜像的完整 digest、来源仓库和拉取时间，这是判断“是否需要重新拉取”的唯一可靠依据。容器实例层记录运行中的容器使用了哪个镜像、映射了哪些端口、挂载了哪些目录，这些信息直接决定对外暴露面。进程入口层则要回答：同一个镜像里是否存在多个运行时入口。

这一层最容易被忽略。命令行、常驻服务进程、Web 服务器加载的模块，可能各自对应不同的运行时版本；只确认其中一个，其余路径依然处于未知状态。原文提到的 PHP 场景就是典型例子：CLI、FPM 和 Apache 模块三条路径需要分别核验，进入容器执行版本命令只能覆盖其中一条。

版本核验要落到小版本

判断是否已修复，不能只看 tag 是否“够新”。以 PHP 的某次安全更新为例，官方修复版本落在明确的小版本号上，而多数镜像 tag 只写到次版本，甚至使用浮动标签。核验时必须进入容器确认实际版本号是否精确匹配，并留意二进制构建时间是否早于修复发布日；版本号对得上、构建时间却偏早，同样需要警惕。

盘点结果应落成一张可核对的表：主机或容器标识、镜像 digest、运行时二进制路径、实际版本号、服务类型、暴露端口、所属业务。这张表的价值不只在于当下修复，更在于后续核验与回滚时有据可查。

让盘点可以重复执行

一次性盘点很快会过期。容器重建、镜像重新拉取、业务扩容，都会让表格失真。可行的做法是把采集动作固化成脚本或配置管理任务，并确保采集命令覆盖所有运行路径，而不是依赖环境变量里默认指向的那个可执行文件。原文提到的批量收集思路同样适用：自动化本身不难，难的是保证覆盖完整。

盘点的终点不是一张漂亮的清单，而是一个能反复回答“现在到底跑着什么”的机制。多容器环境下，运行时依赖本来就是动态的；盘点方法如果不具备可重复性，第一次做完就已经开始失效。