composer audit 能用需同时满足三条件：composer ≥2.5.0、全局启用 experimental.audit、项目存在有效 composer.lock；它仅比对 lock 文件中精确版本与 friendsofphp 安全数据库，不扫描 vendor/、私有包、零日漏洞或运行时环境。
composer audit 能用，但不是装了 Composer 2.5+ 就自动能扫——它默认禁用、只认 composer.lock、不看 vendor/ 目录内容，漏配或漏文件就会静默失败或完全不报漏洞。
确认 composer audit 命令是否真正可用
报 Command "audit" is not defined 或执行后无输出，基本不是拼写错误，而是三个硬性条件没满足：
- 运行
composer --version，必须输出Composer version 2.5.0或更高；低于此版本（如2.4.9）必须先composer self-update - 即使版本达标，也得手动启用实验特性：
composer config --global experimental.audit true（该配置写入~/.composer/auth.json） - 执行
composer list | grep audit，有输出才代表命令已注册成功；若无，别折腾插件，换完整版 Composer
composer audit 必须依赖 composer.lock，不是 composer.json
它不解析你声明的版本范围，只比对 composer.lock 里记录的**精确安装版本**和 FriendsOfPHP 安全数据库是否匹配。常见失效场景：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中跳过
composer install --no-interaction，直接跑audit→ 报错Could not find composer.lock - 本地改了
composer.json但没运行composer install或没提交更新后的composer.lock→ 扫描结果和线上环境脱节 - 用了
--no-install或--dry-run后执行audit→ 锁文件未生成或哈希未更新，扫描无效
让扫描结果真正可操作：关键参数不能少
默认表格输出只列包名和严重等级，修复时还得翻文档查哪个版本修复了漏洞。加这几个参数立刻提升实用性：
-
composer audit --fixed：显示每个漏洞对应的最小修复版本，例如"fixed":"7.5.0"，直接指导升级目标 -
composer audit --format=json：结构化输出，字段含package、version、advisory、fixed，适合 CI 中用jq提取critical条目做门禁判断 -
composer audit --with-dev：默认不扫require-dev下的包，但 CI 构建环节可能加载测试工具链，漏掉等于留后门 -
composer audit --severity=critical,high：只对高危问题失败退出，避免low级别干扰发布节奏
composer audit 扫不到什么，你得心里有数
它不是静态分析器，也不运行代码，更不校验文件完整性。以下情况它完全不管：
- 私有包（未收录进 Packagist 安全数据库）、零日漏洞（刚爆出还没同步）、
.env泄露、配置错误、应用层逻辑漏洞 - 某些漏洞需特定 PHP 版本或扩展（如
gd、openssl）才能触发，audit不做运行时环境检测 - 版本含
-dev、dev-main或 fork 包（如myorg/guzzle），因安全数据库只认原厂名guzzlehttp/guzzle，会直接跳过 - 网络不通导致无法拉取
https://packagist.org/advisories→ 报Could not fetch security advisories，企业内网需配代理或切换数据库源
