composer本身不提供多租户隔离能力，必须依赖服务端鉴权与客户端运行时隔离双层实现；硬编码token到composer.json或项目根目录放auth.json会导致凭据泄露和跨租户包拉取，因其配置静态、无法注入租户上下文。
Composer 本身不提供多租户隔离能力，项目代码隔离权限必须靠服务端鉴权 + 客户端运行时隔离双层实现；硬编码 token 到 composer.json 或在项目根目录放 auth.json 是最常见错误，会导致凭据泄露和跨租户包拉取。
为什么不能靠 composer.json 或 auth.json 实现租户隔离
Composer 的配置是静态的，无法注入运行时租户上下文。常见错误包括：
- 把带 token 的私有仓库 URL 写死在
repositories里，例如"https://token:xxx@pkgs.example.com/tenant-a/"—— 凭据直接暴露在 Git 历史中 - 在项目根目录放
auth.json—— 所有开发者和 CI 共享同一套凭证，失去租户边界 - 用
composer config http-basic...但没加--global，导致配置只对当前目录生效，CI 构建时失效
真实错误现象：安装时出现 401 Unauthorized、package not found（实为权限不足）、甚至意外拉取到其他租户的私有包。
CI 场景下必须动态注入凭据而非静态配置
CI 流程中应避免任何凭据落盘，优先使用环境变量或运行时命令注入：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer config --global http-basic.repo.example.com $USERNAME $TOKEN动态写入全局auth.json，构建完自动销毁 - 设置
COMPOSER_AUTH环境变量，值为 JSON 字符串：{"http-basic": {"repo.example.com": {"username": "u", "password": "t"}} - 禁止在
.gitlab-ci.yml或GitHub Actions中 echo 凭据到文件，改用composer config直接生效
关键点：所有凭据注入必须在 composer install 前执行，且作用域限定为当前 job，不可跨租户复用。
租户级 vendor 目录与 ClassLoader 隔离必须同步做
即使服务端做了鉴权，客户端若共用 vendor/ 或自动加载器，仍会引发类冲突和版本错乱：
- 每个租户必须有独立
composer.json，生成时仅允许name、require、autoload可变，其余字段（如scripts、config）禁止动态生成 -
composer install必须加--no-scripts -d /path/to/tenant/vendor，防止触发全局钩子或写入错误路径 - 入口文件中不能直接
require 'vendor/autoload.php'，而应手动$loader->unregister()后再按需加载，否则多个租户的ClassLoader会互相覆盖 PSR-4 映射
最容易被忽略的是：ClassLoader 是 PHP 进程级单例，只要两个租户的 autoload.php 在同一请求周期内被 require，就必然冲突 —— 这不是 Composer 配置问题，而是 PHP 自动加载机制的硬限制。
