roave 必须作为 dev 依赖安装到项目根目录才生效，因其通过 composer 依赖解析阶段的 conflict 规则拦截含 cve 的包，global 安装无效；它不下载代码、无运行时开销，仅在 install/update 时起作用，且对已安装的危险包静默，需配合 composer audit 检测。
必须作为 dev 依赖装进项目根目录，否则完全不生效 —— 这不是可选项，是 Roave 的工作机制决定的。
为什么 composer global require roave/security-advisories 无效
Roave 不是命令行工具，它靠 Composer 的 dependency resolution 阶段起作用。只有写进当前项目的 composer.json，才会在 install 或 update 时参与版本冲突计算。global 安装的包不会进入任何项目的解析上下文，等于没装。
- 运行
composer global list看到它 ≠ 它在保护你的项目 - 哪怕你 global 装了
dev-latest，composer update monolog/monolog该装带 CVE 的 v2.8.1 还是会装 - 验证方式很简单：删掉项目里的
roave/security-advisories，再跑一次composer require monolog/monolog:2.8.1—— 如果没报错，说明之前根本没生效
composer require --dev roave/security-advisories:dev-latest 的实际效果
执行后，composer.json 的 require-dev 区域会多出一行，但 composer.lock 里不会出现这个包本身 —— 它是个“虚拟约束包”，只提供 conflict 规则。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它不下载任何 PHP 类、不注册 autoloader、不增加运行时开销
- 所有拦截都发生在依赖解析阶段，不是安装后扫描，所以快且确定
- 如果你的
composer.json里有"minimum-stability": "stable"，而dev-latest被当成 unstable，可以临时加"prefer-stable": true或改用roave/security-advisories:6.x-dev（但后者更新滞后） - 别手动编辑
composer.lock绕过它 —— 下次update会重置，且可能引发更难排查的依赖矛盾
报 Your requirements could not be resolved 怎么快速定位源头
这不是失败，是 Roave 正在工作。错误信息里真正关键的是最早被拦下的那个包版本，比如 don't install monolog/monolog v2.8.1，而不是后面一长串推导链。
- 先运行
composer why-not monolog/monolog:v2.8.1，看谁在间接拉这个危险版本 - 检查
composer.json里有没有宽泛约束，例如"monolog/monolog": "^2.8"—— Roave 会封掉整个范围里所有含 CVE 的子版本，包括你没明写的v2.8.2（如果它也有漏洞） - 某些包（如
symfony/http-foundation）在 5.4.x 系列中多个小版本都有不同 CVE，必须升到5.4.33+或直接切6.4+才能解封 - 私有 fork 的包如果没同步上游安全标签（比如你 fork 了
monolog/monolog但没打v2.8.2标签），Roave 无法识别修复状态，会持续报错
最易被忽略的一点：Roave 只拦「将要安装」的包，对已存在的危险包完全静默。如果你的 vendor/ 里早就躺着 monolog/monolog v2.8.1，它不会提醒你 —— 这时候得靠 composer audit（需 Composer 2.5.0+）来扫 composer.lock。
