composer audit 需同时满足三条件才可用：composer ≥2.5.0、全局启用 experimental.audit、项目存在有效 composer.lock；否则报错或静默失效，且仅比对 lock 文件精确版本与 friendsofphp 安全数据库。
composer audit 不能全自动扫描——它需要你手动满足三个硬性条件，缺一不可，否则要么报错、要么静默失效。
composer audit 命令不存在？先看版本和配置
报 Command "audit" is not defined 不是拼写错误，也不是插件没装，而是 Composer 版本或实验特性未启用：
- 运行
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，别折腾旧插件
为什么 audit 总是没输出或报 Could not find composer.lock
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
- CI 流程中跳过
composer install --no-interaction直接跑audit→ 必报Could not find composer.lock - 本地改了
composer.json但没运行composer install，或没提交更新后的composer.lock→ 扫描结果和线上环境脱节 - 用了
--no-install或--dry-run后执行audit→ 锁文件未生成或哈希未更新，结果不可信 - 稳妥做法：CI 中先确保
composer install --no-interaction --no-progress成功，再执行audit
让 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 构建环节可能加载测试工具链（如 PHPUnit 插件），漏掉等于留后门 -
composer audit --severity=critical,high：只对高危问题失败退出，避免low级别干扰发布节奏；注意--severity=medium不生效，别加
audit 扫不到什么，你得心里有数
它不是静态分析器，也不运行代码，更不校验文件完整性。以下情况它完全不管：
- 私有包（未收录进 Packagist 安全数据库）、零日漏洞（刚爆出还没同步到 FriendsOfPHP 数据库）
-
.env泄露、配置错误、应用层逻辑漏洞 - 某些漏洞需特定 PHP 版本或扩展（如
gd）才能触发，audit不检测运行时环境 - 包名含
-dev、dev-main或 fork 包（如myorg/guzzle），而安全数据库只认原厂名guzzlehttp/guzzle
最容易被忽略的是：它只比对 composer.lock 里记录的精确版本，不关心你 composer.json 里写的 ^5.4 —— 如果锁文件里已经是修复后的 5.4.23，那它就不报，哪怕你声明的范围理论上允许旧版。
