Composer 2.x 不支持原生 audit 命令，因其已被移除；应改用 roave/security-advisories 约束、composer install -v 定位冲突，或接入 deps.dev、phpstan-security 等第三方工具进行安全扫描。
composer audit 命令报错 “Command 'audit' is not defined”
这是因为 composer audit 不是 Composer 2.x 的内置命令，它属于官方插件 composer/composer-security-checker（已弃用）或更现代的 roave/security-advisories 生态的一部分。现在真正能用、且被广泛采纳的是 composer audit 的替代方案——composer install --dry-run 配合第三方工具，或者直接使用 composer update --with-dependencies + 安全数据库比对。
实操建议：
- 先确认你用的是 Composer 2.5+：
composer --version，低于这个版本基本不支持原生安全审计 - 运行
composer audit前，必须手动安装插件：composer global require roave/security-advisories:dev-master（注意：这不是运行时命令，而是通过约束阻止不安全包安装） - 更推荐的做法是用独立工具：
composer require --dev overtrue/phplint或直接跑php -r "readfile('https://security.sensiolabs.org/check_lock');"（已停服），现在主流是symfony/cli或deps.devAPI
用 sensiolabs/security-checker 替代方案时提示 “API deprecated”
没错，SensioLabs 在 2021 年底关闭了公开的 security-checker API，所有调用 https://security.sensiolabs.org/check_lock 的脚本都会失败，返回 404 或空响应。这不是你配置错了，是服务端彻底下线。
实操建议：
- 删掉项目里任何硬编码调用该 URL 的脚本或 Makefile 行，比如
curl https://security.sensiolabs.org/check_lock - 改用本地化方案：
composer require --dev roave/security-advisories:dev-latest—— 它会在composer install阶段主动拒绝已知有漏洞的包版本 - 若需扫描历史 lock 文件，可用开源 CLI 工具
phpstan-security或ossindex-cli，它们不依赖 SensioLabs
roave/security-advisories 导致 composer install 失败但没说清哪条包冲突
这个包本质是“黑名单式约束”，它本身不包含代码，只在 composer.json 中声明一堆 "conflict" 规则。一旦某依赖间接拉入一个被标记为不安全的版本，Composer 就会回退、尝试、最终报错，但错误信息往往只显示 Your requirements could not be resolved，不指明具体哪个包踩雷。
实操建议：
- 加
-v参数重试：composer install -v，看最后一段“Resolving dependencies through SAT”里的冲突路径 - 临时移除
roave/security-advisories，再运行composer why-not vendor/package:1.2.3定位具体冲突来源 - 不要盲目升级主依赖，先查
composer show vendor/package看它当前解析出的版本，再对照 Roave 的 conflict 列表 找匹配项
CI 流水线里自动做安全检查但总漏报高危 CVE
单纯靠 roave/security-advisories 或 composer outdated --direct 无法覆盖所有漏洞类型。它只管已知 CVE 是否被收录进其维护的黑名单，而很多供应链攻击（如恶意包名仿冒、post-install hook 注入）或未公开的逻辑漏洞，它完全不感知。
实操建议：
- 在 CI 中加一步
composer validate --strict，防止composer.json被篡改引入非 packagist 源 - 用
composer show --tree结合grep -E "(dev-master|@dev)"扫描不稳定版本，这类版本大概率没经过安全审查 - 关键项目建议接入
deps.dev的 GitHub Action 或phpstan-security，它们会解析composer.lock后向 NVD 数据库比对 CVE ID
真正麻烦的不是找不到漏洞，而是某些包把修复版发在私有分支、没打 tag，或者作者干脆弃坑了——这时候你得自己 fork、打补丁、换源，而不是等 composer audit 给你答案。
