composer audit 是 composer 2.5.0+ 内置命令，需同时满足版本≥2.5.0、启用 experimental.audit 全局配置、项目存在有效 composer.lock 文件；它仅比对锁文件中精确包名与版本和 friendsofphp 安全数据库，不扫描代码、dev 分支、私有 fork 包或 vendor 目录。
直接用 composer audit，别装插件——它从 Composer 2.5.0 起就是官方内置命令，中文环境无需额外配置，但必须满足三个硬条件，缺一不可。
为什么 composer audit 报 “Command not defined”
这不是插件没装，是底层不支持。常见原因就三个：
-
composer --version输出低于2.5.0（比如2.4.9）→ 立即执行composer self-update - 版本够了但
composer list | grep audit没输出 → 运行composer config --global experimental.audit true启用实验特性（写入~/.composer/auth.json） - 某些精简版 Docker 镜像（如
php:8.3-cli-slim自带的 Composer）压根没编译 audit 模块 → 换官方镜像或手动下载完整composer.phar
composer audit 扫什么、不扫什么
它只读 composer.lock，完全不看 composer.json 或 vendor/ 目录内容。匹配逻辑极其严格：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只比对锁文件里记录的**精确包名 + 精确版本号**（例如
"monolog/monolog": "2.10.0"），和 FriendsOfPHP/security-advisories 数据库条目 - 版本含
-dev、dev-main、dev-feature/x→ 主动跳过（数据库不收录不稳定分支） - 私有 fork 包（如
myorg/guzzle）→ 不匹配原厂名guzzlehttp/guzzle，直接忽略，不报错也不提示 - 网络不通时会卡住或报
Could not fetch security advisories→ 加--no-interaction --timeout=30防阻塞
CI 流水线里怎么避免误失败
默认行为太激进：发现任意一条 advisory（哪怕 5 年前的 low 级）就返回非零退出码。生产环境应收紧范围：
- 只扫生产依赖：
composer audit --only=require - 只关注真正要响应的风险：
composer audit --severity=critical --severity=high（注意：--severity=medium无效） - 结构化输出供脚本解析：
composer audit --format=json --no-dev，再用jq '.advisories[] | select(.severity == "critical")' - 想让流水线卡点失败：
composer audit --fail-on-security-violations --severity=critical
扫描结果里看不到 CVE 编号或修复版本？
默认表格输出只列包名和严重等级，修复信息藏在参数里：
- 加
--format=full可看到cve字段和link（指向 NVD 页面），例如：composer audit --format=full | grep -A2 "monolog" - 加
--format=json输出含fixed字段，明确告诉你“升到哪个版本可修复”，适合自动化决策 - 如果某包显示
No vulnerabilities found，先确认composer show vendor/package输出的版本是否真和composer.lock里一致——改过composer.json但没composer install，audit 就永远看不到“潜在风险”
最常被忽略的一点：它只报不修。composer audit 发现 symfony/http-foundation v5.4.0 有漏洞，但不会告诉你该升到 v5.4.23，更不会自动执行 composer update symfony/http-foundation——这个判断和操作，必须由人来闭环，且得结合你实际的 PHP 版本、扩展启用状态和业务逻辑是否真会触发该漏洞路径。
