Composer无全局黑名单，但可通过conflict字段在解析阶段精准拦截特定包版本，repositories.exclude实现源级过滤，roave/security-advisories提供CVE级黑名单；三者均需明确拦截目标与作用环节。
Composer 本身没有「全局黑名单」机制，但可以通过 conflict、repositories.exclude 和插件（如 roave/security-advisories）实现精准排除——关键看你要拦的是「安装行为」还是「解析行为」，以及是否接受中断流程。
用 conflict 字段阻止特定包版本被解析进依赖图
conflict 是最轻量、最可控的排除方式，它在 Composer 解析阶段就报错，不等到下载或安装。但它只对最终进入 composer.lock 的包生效，且必须精确匹配包名和版本约束。
- 想拦死某个已知高危版本：在
composer.json里加"conflict": {"monolog/monolog": "1.23.0"}—— 注意不是"1.23.*"，除非你确认该通配完全覆盖风险范围 - 支持常见版本运算符：
"!= 2.8.1"、"^1.0.0"都可以，但~2.0和^2.0行为不同，别靠猜 - 它不处理间接依赖：如果
package-a依赖monolog/monolog:^1.23，而你只conflict了"1.23.0"，那1.23.1仍会被装上 - 错误示范：
"conflict": {"monolog": "1.23.0"}—— 包名写错（漏了/monolog），整条声明失效
用 repositories.exclude 禁止从某源加载指定包
当你用私有仓库（比如 Satis 或 Artifactory）时，exclude 能防止某包从该源拉取——但它不影响其他源，也不阻止从 packagist.org 安装同名包。这是「源级过滤」，不是「包级拦截」。
- 配置示例：
"repositories": [{"type": "composer", "url": "https://my-internal.repo", "exclude": ["acme/internal-tool"]}] - 仅对当前
repositories条目生效；如果你有多个源，每个都得单独配exclude - 通配符可用：
"acme/*"会排除所有acme/下的包，但"*tool"不合法，不支持后缀匹配 - 注意优先级：如果同一个包在多个源都存在，Composer 会按
repositories数组顺序查找，exclude只跳过当前源的匹配项，不改变查找顺序
用 roave/security-advisories 实现 CVE 级黑名单拦截
roave/security-advisories 是目前最接近「真正黑名单」的方案，但它本质是强制依赖一个禁止列表包，靠 Composer 的依赖求解器自动拒绝冲突版本——不是插件逻辑拦截，而是语义冲突。
- 必须作为
--dev依赖安装：composer require --dev roave/security-advisories:dev-latest，global 安装完全无效 - 它不扫描代码，只比对
roave/security-advisories里收录的已公开 CVE，所以新漏洞披露到被收录之间有延迟 - 一旦触发，错误信息类似：
Root composer.json requires roave/security-advisories, which does not allow monolog/monolog 2.8.1—— 这说明该版本已被标记为不安全 - 不提供修复建议，你得自己查 CVE 编号去翻上游 changelog，确认该升到哪个小版本
为什么不能用 config disable-plugins 或 require-dev 模拟黑名单？
有人试图用禁用插件或把包挪进 require-dev 来“规避”安装，这不可靠：
-
config.allow-plugins控制的是插件执行权，不是包安装权；禁用插件不会让require里的包消失 - 把本该运行时用的包扔进
require-dev，会导致composer install --no-dev后直接Class not found，上线必挂 -
repositories设空或删掉，确实能强制只走 packagist.org，但这不是黑名单，而是源锁定——它不排除 packagist 上的任何包 - 真正难处理的是 fork 后未同步安全标签的私有包：比如你 fork 了
monolog/monolog并打了v2.8.1标签，但官方修复 CVE 的是v2.8.2，Roave 就拦不住你自己的v2.8.1
排除包不是删文件，而是干预 Composer 的依赖解析过程；conflict 最干净，repositories.exclude 最局限，roave/security-advisories 最贴近安全场景——但三者都要求你清楚知道「要拦什么」和「在哪个环节拦」，否则容易漏掉间接依赖或误伤合法版本。
