composer audit 不能自动卡住安装流程，必须手动组合命令、限定参数、验证配置；需确保 Composer ≥2.5.0、启用 experimental.audit、使用完整版；CI 中应设 --severity=high/critical、--no-dev、--format=json，并校验 lock 文件完整性。
composer audit 不能自动卡住安装流程，必须手动组合命令、限定参数、验证配置，否则 CI 里跑十次也等于没扫。
composer audit 命令不存在？先确认三件事
报错 Command "audit" is not defined，基本就卡在这三点：
- 运行
composer --version，必须 ≥ 2.5.0；低于则执行composer self-update - 即使版本达标，也要检查实验特性是否启用：
composer config --global experimental.audit true（该配置写入~/.composer/auth.json） - 某些精简版 Composer（如部分 Alpine Docker 镜像）直接剔除了
audit模块，composer list | grep audit完全无输出——只能换完整版
CI 流水线里怎么让 audit 真正卡住高危漏洞
默认行为会因任意低危告警中断构建，这不是 bug，是设计如此，但你不该让它这么用：
- 只允许高危及以上中断：
composer audit --severity=high --severity=critical --no-dev -
--no-dev必须加：开发依赖（如phpunit/phpunit）常含 RCE 漏洞，不加就等于放行攻击面 - 输出格式要可解析：
composer audit --format=json，再用jq '.advisories[] | select(.severity == "critical")'做精准断言 - 网络超时风险高，CI 中慎用
--force；如需刷新缓存，改用本地预热：composer audit --no-interaction --timeout=15
扫出来漏洞但代码根本没调用？别急着升级
composer audit 不分析调用链，只认 composer.lock 中的精确版本号是否在 FriendsOfPHP/security-advisories 数据库中标记为漏洞：
- 报告了
CVE-2023-1234，但你的代码里从没用过VulnerableClass::doBadThing()→ 属于误报，需人工评估利用条件 - 漏洞可能需特定环境触发：比如
openssl扩展未启用、debug=true关闭、或用户可控输入未进入危险函数路径 - 私有包、fork 包（如
myorg/guzzle）、dev-main分支版本，audit默认跳过且不提示——它不会报错，只会静默忽略
audit 查不到漏洞 ≠ 安全，得补位验证
FriendsOfPHP/security-advisories 数据库只收录主流生态确认并提交的条目，大量中文插件、企业 fork、新披露 CVE 都不在其中：
- 人工核验来源：
composer show w7corp/wechat查 GitHub 地址，确认 stars ≥ 300、最近半年有 commit、LICENSE 明确、Packagist 页面显示 “Verified” - 本地静态扫描：
phpstan analyse vendor/w7corp/wechat/src/检查是否调用eval()、system()、unserialize() - 补位第三方工具：
snyk test --file=composer.lock --severity-threshold=high（注意：会上传 lock 文件，私有项目需评估合规性）
真正容易被忽略的是：audit 的结果高度依赖 composer.lock 的完整性与哈希匹配——手动拷贝 vendor/、删掉 lock 文件、或用 --no-install 跳过安装，都会导致扫描失效。不是“扫了”，而是“根本没扫”。
