composer audit 是 Composer 2.5.0+ 内置的安全检测命令，需满足三条件：版本≥2.5.0、全局启用 experimental.audit、项目存在有效 composer.lock；它仅比对 lock 文件中精确版本与 FriendsOfPHP 安全数据库，不分析代码、不扫描 dev 分支或私有包。
composer audit 是当前最直接、最轻量的依赖安全检查方式，但不是所有环境都能直接用——它只在 Composer 2.5.0+ 中可用，且默认不启用，报 “Command not defined” 或静默无输出，基本都是版本或配置问题。
composer audit 命令为什么不存在或没反应
这不是插件没装，是底层支持缺失。执行 composer audit 报错，常见原因有三个：
- Composer 版本低于 2.5.0：运行
composer --version，若显示2.4.x或更低，必须先升级：composer self-update - 虽是 2.5+ 但未开启实验特性：运行
composer config --global experimental.audit true，该命令会写入全局auth.json，之后composer audit才真正触发扫描逻辑 - 用了精简版 Composer（如某些 Docker 镜像内置的 phar）：它可能剔除了审计模块，
composer list | grep audit完全无输出，只能换完整版
composer audit 扫的是 vendor 还是 composer.lock
它只读 composer.lock，完全不看 vendor/ 目录里的文件内容。锁文件里记录的精确版本号和哈希值，才是它比对安全数据库的唯一依据。
- 你改了
composer.json但没运行composer install→audit不会发现潜在风险 -
vendor/是手动拷贝或 git clone 进来的，composer.lock缺失或哈希不匹配 → 扫描结果为空或漏报 - CI 流水线中跳过
composer install --no-interaction直接跑audit→ 必然失败，因为没锁文件可读
audit 扫描结果为空或漏报的典型场景
看到 “No vulnerabilities found” 不代表安全，很可能是被跳过了：
- 包版本含
-dev、dev-main或dev-feature/x→audit主动跳过，因安全数据库不收录 dev 分支 - 用了 fork 包（如
myorg/guzzle）但 advisories 只认原厂名guzzlehttp/guzzle→ 不匹配，不告警 - 私有包未在
composer.json的repositories中显式声明，或元数据不支持security-advisories字段 → 默认不参与扫描 - 网络不通导致无法拉取
https://packagist.org/advisories→ 报Could not fetch security advisories，企业内网需配代理或切换数据库源
让 audit 输出真正能指导修复的信息
默认表格输出只列包名和严重等级，对修复帮助有限。加参数才能拿到关键信息：
-
composer audit --format=json→ 输出结构化 JSON，适合 CI 解析或存档，字段含fixed（建议升到的修复版本） -
composer audit --fixed→ 显示哪些漏洞已有小版本修复，例如输出{"package":"symfony/http-foundation","version":"5.4.21","fixed":"5.4.22"} -
composer audit --no-dev→ 排除require-dev中的包，缩小范围，适合线上环境快速验证 -
composer audit --ignore=monolog/monolog→ 临时忽略已知但暂无法升级的包（仅限过渡期，勿长期使用）
真正容易被忽略的是：audit 不校验 PHP 自身版本漏洞，也不分析代码逻辑或配置错误（如 .env 泄露），它只回答一个问题——“当前 lock 文件里这些已安装的包，有没有被 FriendsOfPHP/security-advisories 数据库标记为已知高危”。
