composer audit 是 php 8.2 项目依赖漏洞扫描首选，但需满足 composer ≥2.5.0、启用 experimental.audit、存在有效 composer.lock 三前提；默认忽略 dev 包，ci 中须加 --dev --no-interaction；结果可信依赖锁文件与线上环境一致，还需搭配 outdated 和 --dry-run 实现修复闭环。
PHP 8.2 项目做依赖漏洞扫描，composer audit 是首选且官方支持的方案，但它不是“一运行就出结果”的黑盒工具——必须满足三个前提、理解它的能力边界，并配合关键参数才能真正起效。
先确认 audit 能用：三要素缺一不可
Composer audit 在 PHP 8.2 环境下可用，但依赖 Composer 自身版本与配置：
- 运行
composer --version，确保输出 ≥ 2.5.0（如 2.7.3）。低于此版本需先执行composer self-update - 全局启用实验特性：
composer config --global experimental.audit true。该配置写入~/.composer/auth.json，不启用则命令不存在 - 项目根目录下必须存在有效
composer.lock文件——它不是读composer.json或扫描vendor/，只比对锁文件中记录的精确版本与 FriendsOfPHP/security-advisories 数据库
基础扫描：别跳过 --dev 和 --no-interaction
默认情况下，composer audit 会忽略 require-dev 下的包（如 phpunit、phpstan），但这些开发工具一旦存在反序列化或代码注入漏洞，CI 构建阶段反而可能被利用：
- CI 流水线中务必加
--dev和--no-interaction：composer audit --dev --no-interaction - 想聚焦高风险，加
--severity=critical,high，避免 low 级 CVE 干扰发布节奏（注意：--severity=medium不生效） - 若需脚本解析，用
--format=json，输出含package、version、advisory、fixed字段，方便提取关键项
结果可信的前提：锁文件必须准确反映线上环境
audit 报 “No security vulnerability detected”，不代表安全，常见失效原因：
-
composer.lock缺失、为空、被.gitignore忽略，或哈希值与vendor/不一致 → audit 主动跳过 - 改了
composer.json但没运行composer install或composer update→ 锁文件未更新，扫描结果和部署环境脱节 - 用了私有包但未在
repositories中声明，或元数据不含security-advisories兼容字段 → 默认不扫描 - 版本含
dev-main、dev-feature/x等标识 → audit 主动跳过（安全数据库不收录 dev 分支）
不能只靠 audit：搭配 outdated 和 --dry-run 才算闭环
audit 告诉你“哪里炸了”，但不告诉你“怎么修才不连带引爆其他地方”：
- 先跑
composer outdated --all，看清哪些包可升级、是否含传递依赖 - 再执行
composer update --dry-run -v模拟更新过程：看会不会降级、触发 conflict、连带升级 PSR 接口等破坏性变更 - 特别注意输出中带
!的行（如guzzlehttp/guzzle 7.4.5 → 7.5.0 !），说明该版本含已知 BC-breaking，必须查 CHANGELOG - 锁文件变更行数 ≤ 5 行较稳妥；上百行说明波及面过大，建议用
composer update vendor/package-name --with-dependencies小步推进
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
