composer audit 是 composer 2.5.0+ 提供的漏洞扫描命令，仅比对社区维护的 advisory 列表，不自动修复、不分析调用链、不覆盖全部 cve，需配合 --no-dev、--severity=high/critical、--format=json 等参数用于 ci 和精准判断。
composer audit 能快速发现已知漏洞，但不自动修复、不分析调用链、不覆盖所有 CVE —— 它只是第一道过滤网，不是万能解药。
怎么确认 composer audit 能不能用
命令报错 Command "audit" is not defined？先看版本：
- 运行
composer --version，必须 ≥2.5.0 - 低于该版本，执行
composer self-update（需写权限）；若因 PHP 版本太旧升不了，就别硬扛，换snyk test --file=composer.lock或本地 Go 工具 - 注意：
composer security:check是旧命令别名，2.5+ 后已统一为audit，用错会提示未定义
运行 composer audit 时哪些参数最实用
默认输出表格看着全，但 CI 和生产检查中容易误判。真正要加的参数就这几个：
-
--no-dev：跳过require-dev里的包，避免 PHPUnit 插件类低危告警干扰发布流程 -
--severity=high --severity=critical：只报高和严重级，medium和low不会中断命令，也不支持传入 -
--format=json：给 CI 解析用，配合jq '.advisories[] | select(.severity == "critical")'做精准断言 -
--force：强制联网查最新 advisory 数据库，适合本地首次跑或怀疑缓存过期；CI 中慎用，可能因网络超时失败
为什么 composer update 不修复漏洞
这是最常被误解的一点：Composer 不管“安不安全”，只管“符不符合版本约束”。
- 比如
"guzzlehttp/guzzle": "^7.0"，而 CVE-2023-1234 在 7.5.0 修复，但你锁在 7.2.0 ——composer update不会动它，除非 7.5.0 也在^7.0范围内且 packagist 有新版本可选 - 真正起作用的是：手动执行
composer update guzzlehttp/guzzle，或放宽约束再 update，或删掉composer.lock重装 -
roave/security-advisories这类 conflict 包只能预防安装带漏洞的版本，对已存在的漏洞无感，也拦不住composer install从旧 lock 文件恢复
查不到 CVE 就代表安全？别信
composer audit 只比对 FriendsOfPHP/security-advisories 这个社区维护的 JSON 列表，覆盖有限：
- 小众包、私有包、未提交到该库的 CVE，一律不显示
- 有些漏洞需特定扩展（如
openssl）、特定 SAPI（CLI vs FPM）、或配合用户输入才触发，audit 不做上下文判断 - 看到
No security vulnerabilities found不能松气 —— 建议在 CI 中补一道snyk test --file=composer.lock --severity-threshold=high，两者数据源互补
最麻烦的是：它报告了 CVE-2024-5678，但你的代码根本没调那个类、也没开 debug 模式。这时候得人工验证是否真暴露，而不是盲目升级引入 BC break。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
