Roave Security\_Composer 是一个 Composer 插件，仅在 install/update 时比对 SecurityAdvisories 黑名单拦截已知漏洞包，不扫描代码、不调 API、不提供修复建议，需以 --dev 方式安装于项目根目录。
Roave Security\_Composer 是什么，它真能查出漏洞？
它不是扫描器，而是一个 Composer 插件，只做一件事：在 composer install 或 composer update 时，比对已知 PHP 包漏洞数据库（主要用 SecurityAdvisories 这个禁止安装的“黑名单”包），一旦发现你正要装的版本被标记为不安全，就直接中断安装。
它不分析你的代码，不跑静态扫描，也不连外部 API —— 所以快、轻量、可复现，但覆盖范围仅限于社区已公开披露且被收录进黑名单的 CVE。
- 黑名单机制意味着：只要某个包的某版本被 Roave 列入
roave/security-advisories，你就根本装不上它 - 它不提供修复建议，只报错；你得自己决定升级到哪个安全版本
- 不兼容某些私有仓库或 fork 后未同步上游安全标签的包（比如你 fork 了
monolog/monolog但没打v2.8.2标签，而该版本才是修复 CVE 的）
怎么装，为什么不能用 global install？
必须作为 dev 依赖安装在项目根目录，命令是：composer require --dev roave/security-advisories:dev-latest。
别用 composer global require，那玩意儿对当前项目完全无效 —— 因为 Roave 的机制依赖于 Composer 的依赖解析阶段，只有把它写进项目的 composer.json，它才会参与 dependency resolution。
-
dev-latest是推荐写法，它指向最新提交，比固定版本号（如6.x）更能及时拦截新披露漏洞 - 如果你用了
minimum-stability: stable，可能需要临时加"prefer-stable": true配合，否则dev-latest可能被拒绝 - 安装后，
composer.lock里不会出现roave/security-advisories本身，它是个“虚拟包”，只起约束作用
报错 “Your requirements could not be resolved” 怎么快速定位问题？
这不是 bug，是 Roave 正常工作。典型错误信息长这样：Conclusion: don't install vendor/package v1.2.3，后面跟着一串依赖推导链。
关键不是看最后一行，而是找最早那个被拦下的包版本：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer why-not vendor/package:v1.2.3，它会告诉你谁在间接依赖这个危险版本 - 检查你是否手动写了
"vendor/package": "^1.2"这种宽泛约束 —— Roave 会把整个^1.2范围里所有含漏洞的子版本全封掉，哪怕你本意只想装1.2.0 - 有些包（比如旧版
symfony/http-foundation）在 5.4.x 系列里多个小版本都有不同 CVE，这时必须升到5.4.33+或直接切到6.4+才行
和 GitHub Dependabot / Snyk 比有什么实际差异？
Roave 在 CI 里跑得更快、更确定，但信息维度少得多：
- 它不报 CVSS 分数、不给 CWE 编号、不区分“远程代码执行”和“信息泄漏”严重性 —— 对它来说，有 CVE 就是“不能装”
- Dependabot 会提 PR，Snyk 会标出调用链，Roave 只堵住源头，不关心你代码里有没有真用到那个危险函数
- 如果你用的是私有包，或者用了 patch 加固但没发新版，Roave 无法识别这种“事实安全但未被收录”的情况，会误拦
真正容易被忽略的是：它只检查 require 和 require-dev，对 autoload-dev 里加载的测试工具、或 scripts 里调用的 CLI 工具（比如 phpstan）不设防 —— 那些也得单独管。
