需在Dockerfile中安装Composer≥2.5、启用experimental.audit、确保ext-json/ext-curl可用、网络连通Packagist，并先执行composer install生成有效composer.lock，再运行composer audit。
容器里跑 composer audit 不是“加个命令就行”，而是得解决权限、PHP 扩展、依赖隔离和结果输出这四个实际卡点。它默认不进官方 PHP 镜像，且需要 ext-json、ext-curl 和能连 Packagist API 的网络策略，本地验证通过的脚本在容器里常直接报错或静默退出。
怎么让 composer audit 在容器里真正可执行
官方 PHP 镜像（如 php:8.3-cli）压根不带 composer audit 命令——它从 Composer 2.5 开始才作为子命令内置，而多数基础镜像装的是 2.4 或更老版本。别试 composer self-update，容器里没写权限；也别用 apt install composer，Ubuntu 源里的版本太旧，不支持 audit。
- 最稳做法：在 Dockerfile 中用
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer安装最新稳定版 - 必须确认容器内有
ext-json和ext-curl：Alpine 用户要apk add --no-cache curl openssl ca-certificates，否则 HTTPS 请求直接失败，报Curl error: SSL certificate problem - 运行前加
composer --version验证：输出中必须含2.5+，否则audit命令不存在
composer audit 在容器里为什么总返回空或 0
不是没漏洞，是它根本没查——默认只审计当前项目 composer.lock 里已安装的包，而很多 CI 容器构建时没跑 composer install，vendor/ 是空的，audit 就无从下手。另外，它默认不读 ~/.composer/auth.json，若项目用了私有仓库，会跳过对应包的检查。
- 务必先
RUN composer install --no-dev --no-scripts，确保vendor/目录存在且完整 - 私有包审计需显式挂载认证文件：
docker run -v $(pwd)/auth.json:/root/.composer/auth.json ... composer audit - 加
-v参数看真实行为：composer audit -v会打印正在扫描哪些包，卡在某处就说明网络或权限问题
Docker 构建阶段跑 composer audit 的分层陷阱
把它塞进 RUN 指令里看似方便，但一旦审计失败（比如发现高危漏洞），整个镜像构建就中断，CI 流水线直接红掉。而你其实只想记录结果、生成报告，不是阻止发布。
- 正确姿势：用
|| true忽略非零退出码，再把输出重定向到文件：RUN composer audit --format=json > /tmp/audit-report.json || true - 别在最终镜像里留
vendor/和报告文件：多阶段构建中，只在 builder 阶段运行audit，结果 COPY 到单独的审计镜像或上传到 S3 - 注意
--ignore-advisories的副作用：它跳过所有已知漏洞，但参数名易错——写成--ignore-advisory（少个 s）会静默忽略整个选项，导致误报“无风险”
真正难的不是命令跑起来，是让审计结果可信：它依赖容器里 PHP 版本、扩展、网络出口、认证上下文全部对齐开发环境。漏掉任意一环，报告就只是个安慰剂。
