composer install --audit 仅在安装完成后自动调用 composer audit，本身不执行漏洞比对；其效果完全依赖 composer audit 的可用性、配置（如 --severity=critical,high --no-dev --format=json）及 composer.lock 的有效性。
composer install 本身不带安全扫描功能，加 --audit 只是触发后续的 composer audit，它自己不做任何漏洞比对。
composer install --audit 到底做了什么
这个参数不是让 install 过程中实时检测漏洞，而是 install 完成后自动调用 composer audit。它的行为完全取决于 composer audit 是否可用、是否配置正确、composer.lock 是否有效。
- 如果 Composer 版本 --audit 参数会被静默忽略，install 正常完成但不会扫
- 如果全局没启用
experimental.audit，命令会报错：Command "audit" is not defined - 如果项目没有
composer.lock或它被删/损坏，install 成功但audit阶段失败，报错：Could not find composer.lock - 如果 lock 文件存在但内容不完整（比如用了
--no-install），audit会跑，但结果不可信——它查的是“锁里写的版本”，不是“实际装的版本”
为什么 --audit 在 CI 中经常失效
CI 流水线里常见误操作，导致看似跑了 composer install --audit，实则没真正扫描：
- 跳过
composer install --no-interaction，直接执行composer audit→ 没 lock 文件，扫不了 - 用
composer install --dry-run或--no-scripts后再跑--audit→ lock 文件未生成或未更新哈希，比对失准 - 在 Docker 构建中把
composer.lock放在 .dockerignore 里 → 构建镜像时根本没 copy 进去，audit 报错 - Git 仓库里没提交最新
composer.lock，本地改了composer.json但没 commit → 扫描结果和线上环境脱节
如何让 --audit 真正起作用
必须满足三个硬性条件，缺一不可：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer --version，确认输出为Composer version 2.5.0或更高；否则先composer self-update - 执行
composer config --global experimental.audit true，该配置写入~/.composer/auth.json - 确保当前目录有完整、有效的
composer.lock，且内容与vendor/实际安装一致（推荐 CI 中先跑composer install --no-interaction --no-progress，再单独跑composer audit）
验证是否生效：运行 composer list | grep audit，有输出才代表命令已注册成功。
audit 不是万能的，别把它当“全量安全检查”
composer audit 只做一件事：读 composer.lock，逐个比对包名+版本号，查 FriendsOfPHP 安全数据库里的已知 CVE 条目。它不处理：
- 私有包、中文命名包（如
mycorp/支付sdk）、非 Packagist 源的 Git 依赖 —— 全部跳过，不报错也不提示 - 零日漏洞、配置错误（如
.env泄露）、应用层逻辑漏洞、PHP 扩展问题 - dev 依赖默认不扫，加
--all也只扩展传递依赖，不扩展命名空间
真正要覆盖这些盲区，得搭配 snyk test --file=composer.lock 或 cve-check 等外部工具，不能只靠 --audit。
