Composer无全局黑名单机制，但可通过conflict（阻止指定包/扩展）、platform（伪造已存在扩展）、replace（替换不信任包）、repositories（限制安装源）组合实现等效效果。
Composer 本身不支持“禁止安装某类包”这种全局黑名单机制，但可以通过 platform、replace、conflict 和仓库策略组合实现等效效果——关键在于你真正想阻止的是什么：是防止意外引入扩展（如 ext-redis），还是杜绝某些非稳定/非官方的包（如 dev-master 版本），或是屏蔽特定命名空间的第三方库（如 mockery/mockery）？不同目标对应不同手段。
用 conflict 阻止指定包或扩展被安装
这是最直接、最可靠的方式，适用于明确知道要禁用的包名或 PHP 扩展。Composer 在解析依赖时会检查 conflict 规则并报错中断安装。
-
conflict中的包名必须写全，支持版本约束（如"ext-redis": " 或 <code>"monolog/monolog": "*"） - 对 PHP 扩展使用
ext-xxx格式，例如ext-gd、ext-opcache - 该规则只在当前项目生效，不会影响子依赖的内部逻辑，但能阻止它们被选入最终锁文件
{
"require": {
"php": "^8.1"
},
"conflict": {
"ext-redis": "*",
"mockery/mockery": "*",
"phpunit/phpunit": ">=10.0.0"
}
}
用 platform 伪造已存在扩展来绕过 require
当某个依赖声明了 "ext-xxx": "*"，但你实际环境**不装也不打算装**该扩展，又不想改依赖源码时，可用 platform 告诉 Composer “这个扩展已经存在”，从而跳过检查——这不是禁止，而是欺骗，常用于 CI 环境或容器中裁剪扩展。
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
- 仅对
ext-和lib-类型有效，不能用于普通包 - 版本号填什么不重要（Composer 只校验是否存在），但建议填
"*"或"0"避免误触发其他约束 - 若真实环境中缺失该扩展，运行时仍会报错，
platform不解决功能问题，只解决安装问题
{
"config": {
"platform": {
"ext-redis": "0",
"ext-memcached": "0"
}
}
}
用 replace 替换掉你不想要的包
当你发现某个间接依赖强制拉入你不信任/不需要的包（比如一个 SDK 依赖了 guzzlehttp/guzzle，而你只想用 symfony/http-client），可以用 replace 声明“我已提供同名替代品”，从而让 Composer 排除原包。
-
replace后的包不会被安装，也不会被 autoload，适合彻底移除干扰项 - 必须确保你确实提供了兼容接口，否则运行时报
Class not found - 不能 replace 自己未声明的包，且无法 replace 已安装的包（需先
composer remove）
{
"replace": {
"guzzlehttp/guzzle": "*",
"psr/http-client": "*"
}
}
结合 repositories 和 packagist.org 镜像控制来源
如果你的目标是禁止从非官方源安装包（比如禁用私有仓库或 Packagist 的 dev 分支），最有效的是关闭 Packagist 并显式声明可信源：
- 设置
"packagist.org": false后，所有包都必须出现在repositories列表中才可安装 - 可搭配自建 Satis / Private Packagist，或只允许特定组织（如
"github.com/myorg/*"） - 注意：
repositories不过滤类型，只控制来源；它和conflict配合才能做到“只准装 A，不准装 B”
{
"repositories": [
{
"type": "composer",
"url": "https://private.packagist.example.com"
}
],
"packagist.org": false
}
真正难处理的是那些没显式 require、却通过插件或运行时动态加载进来的包——conflict 对它们无效，得靠代码审查、CI 检查 lock 文件或使用 composer show --tree 定期审计。别指望一个配置键解决所有问题。
