composer audit 默认报错是因为它并非 Composer 2.2+ 内置命令，而是由 composer/composer-plugin-security 插件提供，需先全局安装该插件（composer global require composer/composer-plugin-security）才能启用；未安装时提示“Command ‘audit’ is not defined”。
composer audit 命令为什么默认报错？
因为 composer audit 不是 Composer 2.2 之前版本自带的命令，它只在 Composer 2.2+ 中通过 composer-plugin-security 插件提供，且默认未启用。直接运行会提示 Command "audit" is not defined。
真正起作用的是 Composer 官方安全插件，不是核心命令——得先装插件，再用它提供的 audit 子命令。
- 检查 Composer 版本：
composer --version，低于 2.2 的建议升级（composer self-update） - 安装安全插件：
composer global require composer/composer-plugin-security - 插件启用后，
composer audit才能识别并执行
audit 命令的三种常用模式怎么选？
composer audit 默认只检查已安装的依赖（vendor/），但实际场景中你可能想查锁文件、查特定包、或跳过缓存。参数组合直接影响结果范围和响应速度。
-
composer audit：只扫描当前vendor/目录下已安装的包，最快，但无法发现“声明了但没 install”的漏洞（比如require-dev里有高危包但没装） -
composer audit --lock：解析composer.lock，覆盖所有声明的依赖（含require-dev），更全面，适合 CI 流水线 -
composer audit --package=monolog/monolog：精准审计单个包，配合--level=critical可快速确认是否含严重漏洞
注意：--lock 模式要求 composer.lock 存在且格式合法；若项目从未 run 过 composer install，该模式会失败。
输出里的 CVE 编号和 severity 怎么看懂？
audit 输出每行一条漏洞，格式类似：monolog/monolog v1.23.0 has CVE-2017-14998 (critical)。关键信息就三个部分：
-
CVE-2017-14998：这是国家漏洞库编号，可复制到 NVD 查原始披露细节（比如攻击条件、影响版本范围） -
critical：严重等级，取值为critical/high/medium/low，由插件根据 CVE 的 CVSS 分数映射，不是主观判断 - 版本号
v1.23.0：表示该包当前安装/声明的版本存在漏洞；修复方式通常是升到插件提示的“fixed in”版本，如fixed in v1.25.1
别只看 critical 就 panic——有些 critical 漏洞需特殊配置或特定函数调用才触发，得结合项目实际使用方式判断是否真受影响。
为什么 audit 没扫出已知漏洞？常见漏检原因
audit 不是万能扫描器，它依赖上游漏洞数据库（主要是 Symfony Security Checker 的数据源），且只检查 PHP 包层面，不分析代码逻辑。
- 漏洞尚未录入数据库：新披露的 CVE 可能有几小时到几天延迟，
composer audit --update-db可手动更新本地缓存（但不能解决源头未同步问题） - 用了 fork 或私有包：
audit只认 packagist.org 上注册的包名，自定义 VCS repo 或私有仓库中的同名包不会被匹配 - 版本约束太宽（如
"monolog/monolog": "^1.0"）：audit 只校验 lock 文件里锁定的具体版本，不预测未来 install 时可能拉取的危险版本 - PHP 代码里硬编码调用危险函数（如
unserialize()）：这不属于依赖漏洞范畴，audit 不会管
真正要兜底，得把 composer audit --lock 加进 CI 的 pre-commit 或 PR 检查环节，并配合静态分析工具（如 Psalm、PHPStan）补足逻辑层风险。
