白名单配置（如allow-plugins、repositories）仅在项目级composer.json中生效，不支持全局或用户级白名单；其优先级为项目配置＞全局配置＞默认false，且必须精确匹配vendor/name格式。
白名单配置只在项目级 composer.json 中生效
Composer 没有全局或用户级的“白名单”概念，所谓白名单（如 repositories 里限制可拉取的源、或通过 config.allow-plugins 控制插件启用）全部只认当前项目的根目录下的 composer.json。你改了自己家项目的 composer.json，对其他项目完全没影响；你往 Satis 配置文件或包自身的 composer.json 里写 allow-plugins，也压根不会被读取。
allow-plugins 的优先级：项目配置 > 全局配置 > 默认行为
allow-plugins 是 Composer 2.2+ 引入的插件白名单机制，它控制哪些插件类能被自动加载执行。它的生效顺序很明确：
- 如果项目级
composer.json中定义了"allow-plugins": {"vendor/name": true}，则仅允许该插件，其他一律拒绝 - 如果项目级没配，但全局配置（
composer config --global allow-plugins.vendor/name true）开了，就按全局来 - 如果两者都没配，默认行为是
false（即所有插件被禁用），除非你显式设为true或通配符"*"
注意：allow-plugins 不支持部分匹配（比如 "vendor/*" 是无效的），必须写全 vendor/name 形式；且一旦设为 false，连 Composer 自带的 composer/installers 都会被拦住，导致 wordpress-plugin 这类 type 安装失败。
repositories 白名单本质是源地址过滤，不等于包名白名单
很多人误以为把私有 Git 地址写进 repositories 就等于“白名单”，其实这只是告诉 Composer：“这些地址我可以去拉”。真正起过滤作用的是 repositories 的 type 和 url 组合：
-
"type": "vcs"+"url": "https://git.example.com/private/repo"：只允许从这个仓库拉这个包，哪怕 packagist.org 上有同名包也不会用 -
"type": "package"+ 手动声明name和version：相当于硬编码一个包快照，绕过任何远程源 - 没有
repositories条目时，Composer 默认只走 packagist.org（或你全局配置的镜像）
关键点：它不校验包名是否“合法”，也不阻止你 require 一个根本不存在的 name；它只是决定“从哪下”。所以别指望靠它防误装，得靠 require 锁定版本 + composer-unused 扫僵尸依赖。
容易被忽略的兼容性陷阱
白名单类配置在跨环境时特别容易失效，原因往往不在逻辑，而在权限和路径：
-
allow-plugins在 CI 环境中若用 root 用户运行，可能读取的是 root 的全局配置，而不是项目配置 - 私有
repositories若用git@协议，CI 机器必须预装 SSH key，否则会卡在 clone 阶段，报错是Permission denied (publickey)，不是白名单问题，但现象像“不生效” - 某些企业镜像代理会重写
repositories响应体，把原始 URL 替换成内网地址——此时你本地配的allow-plugins仍生效，但实际下载走的是镜像，容易误判为“白名单没起作用”
最稳妥的做法：每次部署前跑一次 composer config --list | grep allow-plugins 和 composer config repositories，确认当前上下文读到的是你预期的值。
