composer audit只比对composer.lock中的精确版本号与FriendsOfPHP/security-advisories数据库的已知漏洞，不扫描源码、不检查vendor/文件、不校验PHP版本兼容性；结果受锁文件状态、网络连通性、镜像源支持度及包元数据完整性直接影响。
composer audit 命令到底查什么
它只比对 composer.lock 中记录的**精确版本号**和 FriendsOfPHP/security-advisories 数据库里的已知漏洞条目，不扫描源码、不检查 vendor/ 目录实际文件、也不管你的 PHP 版本或扩展是否匹配。哪怕你删了 vendor/ 重装，只要 composer.lock 没更新，audit 结果就完全不变。
常见误判来源：
-
composer.lock过期或为空 → audit 主动跳过，输出空白（不是没漏洞，是没数据可比） - 包版本含
dev-main、dev-feature/x等前缀 → audit 默认跳过，安全数据库不收录开发分支 - 私有包未在
repositories中声明为"type": "composer"→ 元数据加载失败，audit 静默忽略 - 用了国内镜像源（如阿里云、腾讯云）→ 多数不同步
security-advisories接口，报Could not fetch advisories: cURL error 7
--severity 和 --no-dev 怎么组合才有效
默认行为会扫所有依赖（含 require-dev），但 CI 卡点或上线前检查必须收缩范围，否则低危提示干扰判断、开发工具类漏洞又容易漏掉真实风险。
- 上线前精简检查（只盯生产环境）：
composer audit --no-dev --severity=critical,high - CI 全量卡点（含测试/构建链路）：
composer audit --dev --no-interaction --severity=critical,high - 想快速确认有没有“真正要动手”的漏洞：
composer audit --format=json --no-dev | jq '.advisories[] | select(.severity == "critical") | .package'（需提前装jq） - 临时豁免某个已知可控 CVE（慎用）：
composer audit --ignore=CVE-2023-12345，但必须在代码注释里写明理由，否则下次审计时没人知道为什么跳过
发现漏洞后，别急着 update
composer audit 只报问题，不提供修复路径。盲目 composer update 可能引入 BC-breaking 更大的问题，比如 Call to undefined method 或 ArgumentCountError。
- 先看漏洞详情里的
affected versions范围，确认当前composer.lock中的版本确实在其中 - 查该包是否被实际调用：运行
composer depends vendor/package-name，如果是not in require且无直接依赖链，风险可能极低 - 升级优先级建议：
– 优先用composer update vendor/package-name --with-dependencies，控制波及面
– 若约束太宽（如"monolog/monolog": "^2.0"），指定最小修复版：composer update monolog/monolog:^2.9
– 升级后必须重新生成并提交composer.lock，否则 audit 下次还是报老问题
最容易被忽略的三个点
一是 composer audit 不校验 platform 配置，比如项目锁死 "php": "8.2"，但新版本依赖只支持 8.3+，audit 完全不提醒，部署时直接崩溃；二是私有包即使加了 "type": "composer"，若响应的 packages.json 缺少 security-advisories 字段或结构不匹配，audit 就当它不存在；三是退出码为 0 不代表安全，得看 JSON 输出里的 advisories_count 字段——有些镜像或网络异常下 audit 会静默返回空结果，却仍 exit 0。
