composer无黑名单插件，靠conflict（解析阶段硬拦截）、roave/security-advisories（cve级间接拦截）和replace（静默跳过）三机制实现：conflict需全包名与精确版本；roave需--dev安装且仅覆盖已收录cve；replace不autoload、不复制文件，纯欺骗依赖图。
Composer 没有真正的“黑名单插件”，所谓黑名单能力，本质是靠 conflict、replace、roave/security-advisories 这三类机制在不同环节做拦截——不是插件功能，而是依赖求解器或包声明层面的语义控制。
conflict 字段：解析阶段硬拦截，最常用也最容易误用
它在 composer install 或 composer update 的依赖解析阶段就报错中断，不等到下载。适合明确知道某包/某版本会引发运行时崩溃、PHP 版本不兼容或扩展冲突的场景。
- 必须写全包名：
"monolog/monolog"不能简写成"monolog"，否则整条失效 - 版本约束要精确：
"*"表示所有版本都不允许；"=2.0.0"可排除中间安全区外的范围 - 它不处理间接依赖的“绕过”：如果 A 依赖 B，B 依赖 C，你只
conflict了 C 的某个版本，而 B 的require允许 C 的其他版本，Composer 仍会选一个不冲突的 C 安装 - 错误信息典型是：
Root composer.json requires monolog/monolog, which does not allow 1.23.0
roave/security-advisories：CVE 级别拦截，但不是实时扫描器
它不是插件，而是一个被强制 require 的“禁止列表包”。Composer 求解器会把它当作普通依赖参与计算，一旦目标包版本出现在它的黑名单里，就会因语义冲突而拒绝安装。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须以
--dev方式安装：composer require --dev roave/security-advisories:dev-latest，全局安装无效 - 只拦截已公开披露且被收录的 CVE，新漏洞从披露到入库有延迟（通常几小时到几天）
- 不提供修复建议，只报错；也不检查你的代码是否真调用了该漏洞函数
- 触发时错误类似：
Root composer.json requires roave/security-advisories, which does not allow monolog/monolog 2.8.1
replace 字段：静默跳过，但风险最高
它不报错、不拦截，只是告诉 Composer “这个包我已经有了”，从而跳过安装。适合你想彻底移除某个间接依赖，且确认项目里完全没用到它提供的类或功能。
- 写法示例：
"replace": {"monolog/monolog": "*"}，"*"最安全，写具体版本可能因上游 require 不匹配而失败 - 它不 autoload 替代包里的任何类，也不会复制文件——纯属欺骗依赖图
- 一旦你后续代码里不小心用了
Monolog\Logger，运行时直接Class not found - 执行后务必用
composer show确认该包确实没出现在已安装列表中
真正容易被忽略的是：这三种方式作用点完全不同——conflict 是求解器层面的拒绝，roave/security-advisories 是靠依赖关系链触发的间接拒绝，replace 是求解器层面的“假装满足”。混用时要注意优先级和副作用，比如 replace 和 conflict 同时存在，可能让 Composer 报出难以理解的循环冲突。
