Composer 不支持白名单配置，所谓“白名单更新”仅是 composer update 后指定包名的临时行为；auth.json 中的域名匹配仅为凭据分发，非访问控制；真需白名单须靠外部脚本校验 lock 文件或使用私有仓库限流。
白名单配置不写在任何 Composer 配置文件里——它根本不是 Composer 原生支持的概念。你看到的“白名单”通常指两种场景：一是 composer update 时显式指定包名（如 composer update monolog/monolog guzzlehttp/guzzle），二是私有仓库或认证场景下对域名、包名、token 的人工校验逻辑，这些必须靠外部脚本或 CI 策略实现，Composer 自身无白名单字段。
composer update 白名单实际怎么用
所谓“白名单更新”，只是 composer update 命令接受包名参数的副作用，并非配置项。
- 执行
composer update vendor/package-a vendor/package-b时，Composer 只会更新这两个包及其满足约束的依赖，其余全部跳过 - 这个行为只在当前命令生效，不会写入任何配置文件，也不会影响下次
composer install - 如果项目有
composer.lock，该命令会按需升级锁文件中对应条目，但不会碰其他已锁定版本 - 错误写法：
composer update --whitelist=...或往composer.json里加"whitelist"字段 —— 这些语法不存在，会被忽略或报错
auth.json 中的域名白名单是假象
auth.json 里看似能“限定”哪些域名走认证，比如只配了 gitlab.example.com，但其实这只是凭据存储位置，不是访问控制开关。
- Composer 发起请求时，只要目标 URL 匹配
auth.json中某条http-basic或github-oauth的 host 键，就自动附带凭证；不匹配就不发，但也不会阻止请求本身 - 没有机制能“禁止访问 packagist.org 以外的源”，除非你手动删掉
repositories配置，或用环境变量COMPOSER_DISALLOW_UNSAFE_REPO强制拦截非 HTTPS 源 - 项目级
auth.json（位于项目根目录）和全局级（~/.composer/auth.json）都只是凭据容器，不参与逻辑判断，“白名单”效果完全取决于你写了哪些域名
真要实现包名白名单，得绕开 Composer 原生命令
如果你需要 CI 或部署阶段强制限制可安装的包（比如只允许公司内部包），必须自己加一层检查，不能依赖 Composer 配置。
- 在
composer install前，用脚本解析composer.lock，遍历packages数组，比对预设白名单列表（如["acme/*", "monolog/monolog"]），不匹配则exit 1 - 避免用正则硬匹配，注意
vendor/name格式与通配符语义（acme/*应匹配acme/http-client，但不匹配acme_tool） - 不要试图在
composer.json的require里动态生成白名单——这会导致composer update无法收敛，且lock文件失去可信度 - 全局配置（
config.json）或auth.json都无法注入这种校验逻辑，它们纯属数据存储，不执行代码
真正容易被忽略的是：白名单需求往往暴露了权限模型缺陷。与其在 Composer 层堵漏，不如控制源头——比如私有 Packagist 镜像本身只同步白名单内包，或用 Satis 构建只含授权包的静态仓库。Composer 不是防火墙，别让它干权限系统的活。
