composer audit 命令从 Composer 2.5.0 版本起才正式内置，低于该版本会报错“Command 'audit' is not defined”；需先运行 composer --version 确认版本，若为 2.4.x 或更低则必须执行 composer self-update 升级。
composer audit 命令到底能不能用？先看版本再动手
不能用 composer audit，大概率不是你写错了命令，而是 Composer 版本太老——这个命令从 2.5.0 才正式内置，低于这个版本会直接报错：Command 'audit' is not defined。
- 运行
composer --version确认当前版本；如果显示2.4.x或更低，必须升级 - 优先执行
composer self-update；若卡住，可强制重装：php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php && sudo mv composer.phar /usr/local/bin/composer - 升级后再次检查，确保输出是
Composer version 2.5.x或更高
为什么运行了 audit 却没输出？常见静默失败原因
没报错也没结果，不等于安全——更可能是 composer.lock 文件缺失、未安装依赖，或包根本不在安全数据库里。
-
composer audit只读composer.lock，不扫描composer.json；没运行过composer install或composer update，lock文件为空或过期，结果就是“查无此包” - 私有包、fork 包、
path类型本地仓库默认被跳过；Packagist 安全数据库（由 FriendsOfPHP 维护）未收录的包，也会显示No security advisories found for package xxx——这不是“安全”，是“没被盯上” - 某些旧包已停止维护（如
guzzlehttp/guzzlev6.x），CVE 可能已不再更新，但漏洞依然存在；别把“没告警”当“没问题”
怎么让 audit 结果真正有用？关键参数和输出解读
默认输出是人话，但 CI/CD 里需要结构化数据；严重等级（low/medium/high/critical）来自 Symfony 安全数据库，不是 CVSS 原始分，别直接换算。
- 加
--format=json输出机器可读格式，适合脚本解析或集成到 GitHub Actions：composer audit --format=json --no-dev > audit.json -
--no-dev跳过开发依赖，避免测试工具（如phpunit）干扰生产环境风险判断 - 输出里看到
doctrine/dbal (cve-2023-30518)这类信息，说明该版本存在已知 SQL 注入风险；但audit不告诉你怎么修——它只负责点名，不负责动刀 - 注意
version字段是你当前锁死的版本，advisory.link指向 Symfony 安全通告页，里面通常含修复建议版本（比如升到3.7.2）
audit 发现漏洞后，下一步该做什么？别只盯着命令本身
composer audit 是个哨兵，不是维修工。它不升级、不替换、不解决依赖冲突——所有修复动作都得你手动介入。
- 先确认影响范围：
composer show doctrine/dbal查当前版本，再跑composer outdated --security看哪些包有带安全补丁的新版 - 尝试精准升级：
composer update doctrine/dbal --with-all-dependencies；如果失败，很可能是依赖树里卡住了旧版symfony/console之类间接依赖 - 别滥用
config.advisories-bypass屏蔽 CVE——这是临时止血，不是创可贴；长期留着等于在日志里写“我知道这很危险，但我懒得改” - CI 中建议设为门禁：
composer audit --no-dev || exit 1，但要配合--format=json+ 解析脚本，才能区分 low 和 critical，避免误伤
最常被忽略的一点：audit 只查已知漏洞，对供应链投毒（比如恶意 post-install-cmd）、零日漏洞、未公开的私有包风险完全无感。它值得每天跑一次，但不能代替代码审查和最小权限原则。
