composer audit 是 composer 2.5.0+ 内置的安全检查命令，需满足版本≥2.5.0、启用 experimental.audit 全局配置、存在有效 composer.lock 三条件；它仅比对 lock 文件中精确版本与 friendsofphp 安全数据库，不扫描代码、dev 分支、私有包或 platform 依赖。
composer audit 是当前最直接、最轻量的 Composer 安全检查方式，但它只在 Composer 2.5.0+ 中可用，且默认不启用——看到 “Command not defined” 或静默无输出，基本都是版本或配置问题，不是插件没装。
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 --fixed：显示每个漏洞对应的“最小修复版本”，例如"fixed":"5.4.22"，直接指导升级目标 -
composer audit --format=json：输出 JSON 格式，字段含advisory、severity、package、version等，适合 CI 解析 -
composer audit --severity=high --severity=critical：只对高危问题返回非零退出码，避免 low 级别干扰发布节奏 -
composer audit --no-dev：忽略require-dev中的包（生产环境推荐），但 CI 构建环节建议保留--dev，否则测试工具链漏洞会被豁免
它不分析代码调用、不判断是否真用到了漏洞路径、也不校验 PHP 版本或扩展兼容性；composer.lock 一旦不准，结果就不可信；私有包和 fork 包默认静默跳过，得靠人工补位或第三方工具交叉验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
