composer audit 无反应的主因是功能未加载，常见于 Composer 版本过低、实验特性未启用或二进制裁剪；其依赖 composer.lock，且默认对任意漏洞返回非零码，需按需配置严重级别、超时、格式等参数。
audit 命令根本没反应，连报错都没有
这不是网络或配置问题，是功能压根没加载。常见原因有三个：
-
composer --version输出低于2.5.0→ 必须先执行composer self-update - 版本达标但
composer list | grep audit无输出 → 实验特性未启用，运行composer config --global experimental.audit true - 用了裁剪版
composer.phar（比如某些旧 Docker 镜像）→ 审计模块被移除，self-update可能失败，只能换官方完整二进制
注意：composer audit 不读 composer.json，只依赖 composer.lock。该文件若为空、被 .gitignore 忽略、或哈希与 vendor/ 不一致，audit 会静默跳过，不报错也不输出。
audit 扫出一堆 low/medium 级漏洞，但 CI 卡住了
默认行为是：只要发现任意一条 advisory，就返回非零退出码。CI 流水线里不该照单全收。
- 生产卡点只关注真正可利用的风险：
composer audit --severity=critical,high --no-dev - 避免交互中断流水线：
composer audit --no-interaction - 网络不稳定时防超时：
composer audit --timeout=30 - 结构化输出供脚本解析：
composer audit --format=json --no-dev，再用jq '.advisories[] | select(.severity == "critical")'提取关键项（需提前装jq）
忽略已知可控漏洞要慎用：composer audit --ignore=CVE-2023-12345，但必须在代码注释或文档里写明豁免理由。
audit 显示 “No advisories found”，但项目其实有高危 CVE
这不是工具失效，而是数据源或配置未就位。重点排查四点：
-
composer.lock过期或未生成 → 先跑composer install或composer update - 用了私有仓库但未在
composer.json的repositories中声明，或该源不提供security-advisories字段 → audit 默认跳过 - 镜像源不支持安全通告接口 → 国内多数镜像（如阿里云、腾讯云）不同步
security-advisories数据，临时切回官方源：composer config --global repo.packagist.org https://packagist.org - 包版本含
dev-main、dev-feature/x等标识 → audit 主动跳过，因安全数据库不收录开发分支
更隐蔽的问题是：漏洞不在 FriendsOfPHP/security-advisories 库中。这个库只收 Symfony/Drupal/Laravel 等主流生态确认过的条目，小众包或新披露未同步的 CVE 就查不到，得人工查 GitHub SECURITY.md 或 Snyk 补充。
audit 发现了漏洞，但不知道怎么修
composer audit 只报告，不修复、不升级、不改 composer.json。修复动作仍是手动操作：
- 升到已修复版本：
composer update vendor/package，或指定版本：composer update monolog/monolog:^2.9 - 如果当前
require约束太宽（如"monolog/monolog": "^2.0"），而修复版是2.9.0，update可能不会命中，需显式指定 - 升级后务必补跑
composer validate --strict，它不查漏洞，但会校验platform配置是否合理（比如 PHP 版本、扩展是否存在），避免部署失败
最常被忽略的是：audit 不扫描 require-dev 下的包，默认跳过 phpunit/phpunit、mockery/mockery 等——CI 流水线里漏掉 --dev 参数，等于把一大半攻击面直接豁免。
