composer本身不支持多租户隔离，所有权限控制必须由服务端实现；镜像地址统一，隔离依赖反向代理、私有仓库鉴权或ci凭据路由，而非客户端静态配置。
Composer 本身不支持多租户隔离，所有权限控制必须落在服务端——镜像地址（如 https://repo.example.com）对所有租户是相同的，真正起作用的是反向代理、私有仓库服务或 CI 环境中的凭据路由与限流策略。
为什么不能靠 composer.json 或 auth.json 实现租户隔离
Composer 的配置文件是静态声明式结构，不支持运行时变量、条件 require 或租户上下文注入。硬编码租户凭据到项目级 auth.json 是最常见错误：它导致所有开发者和 CI 共享同一套 token，直接绕过隔离；错误现象包括 401 Unauthorized、package not found（实为权限不足）、甚至拉取到其他租户的私有包。
-
auth.json应仅存在于用户主目录（~/.composer/auth.json），权限设为600 - CI 场景下优先用
composer config http-basic.repo.example.com username password --global动态注入，避免检入凭据 - 绝不在项目根目录放
auth.json，也不在composer.json的repositories中写死带 token 的 URL（如https://token:xxx@pkgs.example.com/tenant-a/）——这会泄露凭证且无法按租户动态切换
Private Packagist 与 Satis 的租户路由差异
两者都需把“租户”映射为不同身份凭证下的仓库访问权限，但鉴权机制完全不同：
-
Private Packagist 原生支持
team+repository access control，可为每个团队分配特定私有包的读写权限，无需额外网关 -
Satis 不自带鉴权，必须前置 Nginx/Apache 做
auth_basic，再根据$remote_user动态生成不同packages.json；若用 Laravel 自建 Repository，需在服务端解析请求头中的X-Tenant-ID或 token，返回对应租户的包列表 - 无论哪种方案，
composer install请求最终到达的仍是同一个镜像域名，隔离点始终在服务端路由逻辑，而非客户端配置
缓存、带宽与存储的三层隔离实操要点
租户间资源争抢常发生在缓存目录、镜像出口带宽和后端存储路径三个层面，必须显式隔离：
-
COMPOSER_CACHE_DIR必须按租户独立设置，例如/tmp/composer-cache-tenant-a；Docker 构建中禁止挂载全局~/.composer/cache - 带宽配额只能在 HTTP 层实现：Nginx 使用
limit_req按请求头（如X-Tenant-ID）做令牌桶限速，例如每分钟最多 50 个.zip下载请求 - 私有镜像后端存储需按租户分桶，例如 S3 路径
s3://my-repo/tenants/tenant-a/packages/，Artifactory 则需为每个租户创建独立repository key并绑定 ACL 与配额策略
动态生成 composer.json 的安全边界与执行约束
多租户 SaaS 必须为每个租户生成独立 composer.json 并隔离 vendor 目录，否则版本冲突（如 monolog/monolog:^2.0 vs ^3.0）将引发 Class not found 或安装失败。
- 仅允许动态字段：
name（建议设为tenant/{id}）、require（需校验白名单与语义化版本，拒绝1.*.*等模糊写法）、autoload（如 PSR-4 映射到租户专属目录） - 禁止动态字段：
autoload-dev、scripts、config.process-timeout等部署环境控制项 - 安装命令必须加
--no-scripts并用-d指定租户目录：composer install --no-scripts --no-interaction -d "tenants/{$tenantId}"
真正的难点不在生成 JSON，而在服务端如何安全地校验租户输入、防止包名注入与版本越权；一旦漏掉白名单校验，laravel/framework:dev-master 这类危险依赖就可能被注入。
