composer audit 命令需 Composer 2.5.0+ 才稳定可用，依赖 composer.lock 精确版本扫描，不分析调用链或运行时环境，CI 中建议限定严重级别并设超时。
别用 Roave/security-advisories 了——它不扫描，只拦安装，和 composer audit 完全不是一回事。
为什么 composer audit 报错 “Command ‘audit’ is not defined”？
这是最常卡住人的第一步：你的 Composer 版本太低。从官方记录看，audit 命令在 2.2.0 才首次内置，但真正稳定、默认启用且覆盖完整安全数据库的，是 2.5.0+。低于这个版本，命令根本不存在。
- 检查当前版本：
composer --version—— 如果输出是2.4.x或更低，就别折腾插件，直接升级 - 升级命令：
composer self-update（确保已配国内镜像，否则可能卡在 TLS 握手） - 验证是否生效：
composer list | grep audit应该能看见audit行 - 企业环境若锁死旧版（如因 PHP 7.2 不兼容），
roave/security-advisories也救不了——它只在require阶段做拦截，对已安装的老包完全无感
composer audit 扫的是 vendor 还是 composer.lock？
它严格依赖 composer.lock 中记录的**精确安装版本**，而不是 vendor/ 目录里“看起来像”的文件，也不是 composer.json 里写的模糊约束（比如 "^5.4"）。所以你改了 composer.json 却没跑 composer install，audit 就不会反映潜在风险。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 常见误判场景：本地
vendor/是手动拷贝或 git clone 进来的，composer.lock缺失或哈希不匹配 →audit结果为空或漏报 - 临时验证方法：删掉
vendor/和composer.lock，重新composer install再跑composer audit - 私有包必须在
composer.json的repositories中显式声明，且元数据需支持security-advisories字段，否则不会被纳入扫描
CI 流水线里 composer audit 总失败？不是漏洞多，是默认策略太激进
默认情况下，只要发现任意一条 advisory（哪怕只是 low 级别、5 年前的过时条目），audit 就返回非零退出码，导致 CI 直接中断。这不是 bug，是设计如此——但你不该让它这么用。
- 生产环境卡点建议：
composer audit --severity=critical --severity=high --no-dev，只关注真正可利用的高危项 - 网络不稳定时加超时：
composer audit --no-interaction --timeout=30，避免因拉不到 Packagist 安全库而卡住 - 想让结果可解析？用 JSON：
composer audit --format=json | jq '.advisories[] | select(.severity == "critical")'（需提前装jq） - 注意：
--ignore-severity=low这类参数在部分旧版 2.5.x 中不生效，优先用--severity=显式指定
报了 CVE，但我的代码根本没调那个函数，还要升级吗？
composer audit 不分析调用链，也不检测运行时环境（比如是否启用了 gd 扩展、是否开了 debug 模式）。它只比对包名 + 版本号是否落在 FriendsOfPHP/security-advisories 数据库的“受影响范围”里。
- 先查原始 advisory：
symfony/cve-2023-1234这种 ID 去 FriendsOfPHP/security-advisories 看描述，重点关注 “Exploitation conditions” - 有些漏洞需用户可控输入 + 特定配置组合才触发，你的用法可能天然免疫；但也有些看似“用不到”的类，在框架自动加载或事件监听中被间接调用
- 盲目升级可能引入 BC break；更稳妥的做法是写个最小复现脚本，验证漏洞路径是否真能走通
真正容易被忽略的点是：audit 不报错 ≠ 没漏洞，它只报数据库里已收录、且版本完全匹配的条目；新披露的 0day、非 Packagist 包、或自定义 fork 的分支，它一律不覆盖。
