composer audit不是修复命令，仅报告被公开标记为有风险的包；需Composer≥2.5.0、启用experimental.audit、存在有效composer.lock且能连Packagist安全数据库才可用。
composer audit 输出的不是“要不要修”的清单，而是“哪些包被公开标记为有风险”的快照——它不判断你是否真受影响，也不管你有没有实际调用漏洞代码。
为什么 composer audit 没输出或报 “Command not defined”
这不是配置问题，是功能压根没启用或不可用。
-
composer --version低于2.5.0→ 命令不存在，必须先运行composer self-update - 版本 ≥ 2.5.0 但
composer list | grep audit无结果 → 实验特性未开启，执行composer config --global experimental.audit true - 用的是裁剪版
composer.phar（比如某些旧 Docker 镜像）→ 审计模块被移除，self-update可能失败，只能换官方完整版 -
composer.lock缺失、为空、被.gitignore忽略，或哈希与vendor/不一致 →audit主动跳过，静默退出
composer audit 扫描范围和常见误判点
它只看 composer.lock 里记录的精确包名+版本号，不读 composer.json 的约束，也不检查 vendor/ 实际文件内容。
- 私有包未在
composer.json的repositories中声明，或元数据不含security-advisories字段 → 默认不扫描 - 版本含
dev-main、dev-feature/x等标识 →audit主动跳过（安全数据库不收录 dev 分支） - 改了
composer.json但没跑composer install或composer update→lock文件未更新，审计结果不会反映潜在风险 - 镜像源配置错误（如阿里云、腾讯云镜像）→ 安全数据库接口不同步，
audit拉不到数据，结果为空或不准
CI 流水线里怎么用 composer audit 才不卡构建
默认行为是：只要发现任意一条 advisory（哪怕是个 5 年前的 low 级 CVE），就返回非零退出码。这会直接让 CI 失败，但通常不该这样。
- 生产卡点只关注真正可利用的风险：
composer audit --severity=critical --severity=high --no-dev - 网络不稳定时防卡住：
composer audit --no-interaction --timeout=30 - 结果要供脚本解析：
composer audit --format=json --no-dev | jq '.advisories[] | select(.severity == "critical")'（需提前装jq） - 想忽略已知可控漏洞（慎用）：
composer audit --ignore=CVE-2023-12345，但必须在代码注释或文档里写明豁免理由
真正容易被忽略的是：审计结果只反映「已公开披露且被收录」的漏洞，不覆盖未上报、0day、或仅影响特定配置路径的情况；同时，它无法替代代码级审查——比如一个包本身无漏洞，但你的调用方式绕过了它的防护逻辑，audit 完全看不到。
