Composer 2.5+ 内置 composer audit 命令但需手动升级并启用，它依赖 packagist.org 安全数据库检测已锁定包的漏洞，不自动修复、不处理间接依赖冲突，输出含 severity 和 solution 字段供人工决策。
Composer 本身不自带 composer audit 命令——它是在 Composer 2.5+ 中才正式引入的内置安全审计功能，但默认未启用，且依赖外部服务（packagist.org 的安全告警数据库）。如果你执行 composer audit 报错 “Command ‘audit’ is not defined”，大概率是因为版本过低或未启用安全插件。
确认 Composer 版本并升级到 2.5+
低于 2.5 的 Composer 完全没有 audit 子命令。运行以下命令检查：
composer --version
若输出类似 Composer version 2.4.4，必须升级：
- 全局升级：
composer self-update - 如仍卡在 2.4.x，可能是被镜像或旧安装方式锁定，可强制重装：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php && sudo mv composer.phar /usr/local/bin/composer - 升级后再次运行
composer --version确认 ≥ 2.5.0
运行 composer audit 的正确姿势
composer audit 默认只检查 composer.lock 中已安装的包（即生产依赖），不扫描 require-dev，也不主动更新 lock 文件。常见误操作包括：
- 没加
--locked却期望检查当前 lock 状态（其实它是默认行为，但显式写上更稳妥） - 忘记先
composer install或composer update，导致 lock 文件陈旧，漏报已修复但未锁定的漏洞 - 在 CI 环境中因网络限制无法访问 packagist.org/security-advisories.json，会静默跳过审计
推荐执行流程：
composer install --no-interaction composer audit --locked --format=json
--format=json 输出结构化结果，方便脚本解析；省略则为人类可读格式（含颜色）。
理解 audit 输出中的关键字段
JSON 输出里每个漏洞项包含 advisory、package、version、solution 等字段。重点看：
-
"severity": "critical"或"high"：需立即处理；"low"通常指信息泄露类，影响有限 -
"solution"字段给出具体修复建议，例如："Update foo/bar to version 2.3.1 or higher."—— 注意它不自动执行 update，只是提示 -
"cve"字段为空？别慌，Packagist 安全库不强制要求 CVE 编号，很多 PHP 生态漏洞只有自定义 ID（如symfony/serializer的sf-2022-01）
audit 不解决的问题，你得手动做
composer audit 是检测工具，不是修复工具。它不会：
- 自动
composer update foo/bar—— 即使solution写了“update to 2.3.1”，你也得自己执行 - 处理间接依赖（transitive dependencies）的冲突：比如 A 依赖 B@1.0，B@1.0 有漏洞，但 A 锁死了 B 的版本，此时
audit会报出，但composer update A可能因兼容性失败而无法升级 B - 识别本地修改过的包（如
path类型仓库）—— 这些包不在 Packagist 数据库中，audit 直接跳过
真正卡住的地方往往不是“有没有漏洞”，而是“能不能安全升级”。这时候得看 composer why-not foo/bar:2.3.1 查阻塞源，再决定是升级上游、打 patch 还是临时忽略（用 --ignore 参数，但需记录原因）。
