composer audit 能用需同时满足三条件：Composer ≥ 2.5.0、命令已加载（composer list | grep audit有输出）、实验特性开启（composer config --global experimental.audit true）；缺一则报错或静默失效。
composer audit 不是“一装就用”的命令，它在 2.5.0+ 才存在，且默认不启用——直接运行大概率报 Command "audit" is not defined 或静默无输出。别猜，先验证再操作。
怎么确认 composer audit 真的能用
不是版本够了就行，得同时满足三个条件：Composer ≥ 2.5.0、命令已加载、实验特性已开启。
- 运行
composer --version：必须输出类似Composer version 2.5.12；2.4.x 及更低版本压根没这个命令 - 运行
composer list | grep audit：没输出 = 命令未加载，不是拼错了，是根本没注册进来 - 若版本达标但命令仍不可见，执行
composer config --global experimental.audit true启用实验特性（该配置写入全局auth.json） - 某些企业定制版
composer.phar（如锁定 PHP 7.2 的旧镜像）可能压根没编译审计模块，此时self-update会失败，只能换基础镜像或手动下载官方 phar
为什么 composer audit 明明有漏洞却不报
它只比对 composer.lock 里记录的精确包名 + 精确版本号，和 FriendsOfPHP/security-advisories 数据库里的条目。不扫描代码、不查 NVD、也不管你 PHP 版本或配置是否触发漏洞。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer.lock缺失、被.gitignore掉、或内容损坏 → audit 无输入，结果为空 - 你手动复制了
vendor/，没走composer install→ lock 文件里的dist.shasum与实际文件不匹配，audit 主动跳过校验 - 包名是 fork 版（如
myorg/guzzle），而数据库只认guzzlehttp/guzzle→ 直接忽略，不报错也不提示 - 版本带
-dev、dev-main等不稳定标识 → advisories 不收录，audit 主动跳过 - 用了私有仓库但没在
composer.json的repositories里声明security-advisories元数据 → 不参与扫描
composer audit 在 CI 流水线里怎么不误杀
默认行为是：只要发现任意一条 advisory（哪怕 5 年前的 low 级条目），就返回非零退出码。这不是 bug，是设计如此——但你不该让它这么跑。
- 生产环境卡点只关注真正可利用的风险：
composer audit --severity=critical --severity=high --no-dev - 网络不稳定时防卡住：
composer audit --no-interaction --timeout=30 - 结果要供脚本解析：
composer audit --format=json --no-dev | jq '.advisories[] | select(.severity == "critical")'（需提前装jq） - 想忽略已知可控漏洞（慎用）：
composer audit --ignore=CVE-2023-12345，但必须在代码注释或文档里写明豁免理由 - 内网 CI 若无法访问
packagist.org，先确认镜像源是否同步安全数据库；否则临时切回官方源：composer config --global repo.packagist.org composer https://packagist.org
composer audit 扫完之后怎么办
它只提示，不升级、不降级、不改 composer.json。所有修复动作仍是手动闭环。
- 定位到问题包后，先确认当前
require约束是否太宽（如"monolog/monolog": "^2.0"），再执行composer update monolog/monolog拉取修复版 - 若需指定版本（如修复版是
2.9.0），用composer update monolog/monolog:^2.9 - 注意：audit 不判断你是否真用到了漏洞路径。报告了
CVE-2023-1234，但你的代码里根本没调SomeVulnerableClass::doBadThing()—— 这时得人工评估实际风险，而非盲目升级引入 BC break - 最关键的盲区是间接依赖：如果某个关键间接包（如
symfony/polyfill-mbstring）没出现在composer.lock里（比如被conflict排除），audit 就扫不到——最可靠方式是先composer show --locked | grep polyfill确认它是否真被安装
