composer.lock 不是安全工具，仅记录依赖快照；composer audit 才负责漏洞扫描，但必须依赖准确、未被忽略且内容完整的 lock 文件，二者缺一不可。
composer.lock 本身不审计，只记录快照
它不是安全工具，而是一份「依赖执行清单」：精确到每个包的 version、dist.sha256、source.reference，甚至扩展要求（如 ext-json）。只要 composer.lock 存在，composer install 就完全忽略 composer.json 里的 "^2.0" 这类模糊约束，只按锁文件装。
但这份清单不包含任何漏洞信息——它不会告诉你 monolog/monolog 的 2.9.1 版本是否含 CVE-2026-1234。它只说“我装了这个”，不说“这个安不安全”。
- 删掉
composer.lock后直接composer install，新版 Composer 会报Command "install" is not defined，不是提示你补文件，而是拒绝执行 -
composer.lock被.gitignore忽略 → CI 节点各自解析依赖 → 不同机器装出不同guzzlehttp/guzzle小版本，环境彻底失控 - 私有包没在
repositories中声明，或元数据不含security-advisories字段 →composer audit默认跳过，不报错也不扫描
audit 命令必须依赖 lock 文件才能工作
composer audit 不读 vendor/ 目录，也不看 composer.json，它唯一输入就是 composer.lock。它把里面每个包的 name 和 version 拿去查 Packagist 的 /advisories 接口，匹配已知 CVE。
所以：composer.lock 错误 = audit 结果失效；lock 没更新 = audit 查不到新披露漏洞；lock 里有 dev-main 版本 = audit 主动跳过（安全库不收录 dev 分支）。
- 执行
composer audit返回No security vulnerability detected，但实际存在高危漏洞？先检查composer.lock是否真实存在、未被.gitignore屏蔽、且内容非空 - CI 中
audit总失败？默认行为对任意一条 advisory（包括 low 级）都返回非零退出码。生产卡点应加--severity=critical,high --no-dev - 企业内网跑
audit报Could not fetch advisories: cURL error 7？不是项目问题，是网络或镜像源配置问题——阿里云、腾讯云等国内镜像不提供/advisories接口同步
lock 文件 + audit 是咬合关系，缺一不可
只靠 composer.lock，你能保证“每次部署装的是一样的”，但无法判断“装的这一样是不是危险的”。只跑 composer audit，若没有准确的 lock，它连该查哪个版本都不知道。
真正起作用的是组合：lock 文件锁定“是什么”，audit 验证“这个是什么有没有问题”。两者在 CI 中必须串联验证，不能只做一半。
- CI 第一步必须
git diff --quiet composer.lock，防止本地漏提交导致后续所有检查失真 - 必须先
composer install --dry-run确认 lock 可复现，再跑composer audit --severity=critical,high --no-dev，否则 audit 成了空中楼阁 - 发现漏洞后，不能只改
composer.json然后composer update—— 必须重新生成composer.lock并提交，否则下一次audit仍基于旧快照
容易被忽略的三个硬性前提
很多人以为装了 Composer 就能用 audit，其实它有一串隐性开关，少一个就静默失效：
-
composer --version必须 ≥2.5.0（当前稳定版是2.9.6），旧版无此命令 - 必须执行过
composer config --global experimental.audit true，否则composer list | grep audit不会输出 - 网络必须能访问
https://packagist.org/advisories，代理、防火墙、镜像源配置错误都会让audit返回空结果而非报错
这些条件不满足时，composer audit 不会报错，只会安静地什么也不做——这才是最危险的情况。
