composer audit 无输出是因为它仅基于 composer.lock 审计，且依赖四个前提：lock 文件存在且未被忽略、与 vendor 哈希一致、所有包在 repositories 中声明、版本号为稳定版；镜像不支持 security-advisories 接口也会导致失效。
composer audit 为什么没报任何漏洞？
常见现象是执行 composer audit 后输出空白或提示 “No advisories found”，但项目其实存在已知 CVE。根本原因不是工具失效，而是它只读 composer.lock，且严格依赖四个前提：
-
composer.lock必须存在、非空、未被.gitignore忽略；删了或漏提交 = 审计直接跳过 - 当前
composer.lock必须与vendor/目录哈希一致；手动改过 vendor 或删过目录后没重装，会导致锁文件“过期” - 所有包必须在
composer.json的repositories中声明；私有包若没配源或源不支持security-advisories接口，audit 就看不见 - 版本号不能含
dev-、alpha、rc等标识；安全数据库不收录非稳定分支
CI 流水线里 audit 总失败，怎么卡得准又不误伤？
默认行为是发现任意一条 advisory（哪怕 low 级）就返回非零退出码，这在 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，但必须在代码注释里写明豁免理由和临时缓解措施
镜像源配置错误会让 audit 彻底失效
audit 数据来自 Packagist 官方的 security-advisories 接口，而多数国内镜像（如阿里云、腾讯云）并不同步该接口。现象是报错 Could not fetch advisories: cURL error 7 或静默无输出。
验证方式：curl -I https://packagist.org 看是否通；临时切回官方源：composer config --global repo.packagist.org composer https://packagist.org。
长期方案不是换镜像，而是确认你用的镜像是否明确声明支持 security-advisories —— 目前只有少数企业级镜像（如私有 Satis + 自建 advisory 同步服务）能做到这点。
audit 发现了漏洞，下一步必须手动干预
composer audit 只提示，不修复、不升级、不改 composer.json。它甚至不会告诉你该升到哪个版本。
- 先看 advisory 描述里的
cve或fixed in字段，确认修复版本（如monolog/monolog需升至^2.9.0） - 检查当前
composer.json的约束是否允许该版本；如果写的是"monolog/monolog": "^2.0"，直接composer update monolog/monolog即可 - 如果约束太紧（如
"^2.6"），而修复版是2.9.0，就得手动放宽或指定版本：composer require monolog/monolog:^2.9 - 更新后务必再跑一次
composer install --dry-run，确认没引入 PHP 版本冲突或子依赖矛盾
真正容易被忽略的是：audit 结果依赖 lock 文件的时效性。发现漏洞后只改 composer.json 不运行 composer update，lock 文件不会变，下次 audit 还会报同一问题。
