不能共享 composer 缓存镜像，也不该尝试共享，因 auth.json 凭证泄露、config.json 环境差异、cache/ 哈希校验失败及 vendor/bin 软链接断裂等问题会导致直接失败；应统一镜像配置并各自维护独立缓存。
不能共享 Composer 缓存镜像，也不该尝试共享。 所有试图让多个用户共用 ~/.composer/cache 或统一 COMPOSER_HOME 的做法，都会在 auth、权限、PHP 环境差异和缓存校验上出问题——不是慢一点，而是直接失败。
为什么 COMPOSER_HOME 不能多用户共享
Composer 的全局目录（默认 ~/.composer）里混着几类强用户绑定的数据：
-
auth.json存的是个人私有仓库 token，共享等于泄露凭证 -
config.json里的 proxy、repo 镜像、cache-dir 路径等，每个用户网络环境不同，硬统一会失效 -
cache/下的 zip 包哈希值，依赖 PHP 版本、扩展（如 openssl 版本）、甚至 glibc 小版本；同一份缓存，在 A 机上校验通过，B 机上可能报Hash mismatch -
vendor/bin/里的全局命令（如laravel）是软链接，指向各自安装路径，共享会导致链接断裂或覆盖
团队该怎么做：统一配置 + 各自缓存
目标不是“共享缓存”，而是“让所有人走同一镜像、用各自干净缓存”。关键动作如下：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每个成员在自己的 shell 初始化文件（如
~/.bashrc）里加一行：export COMPOSER_HOME="$HOME/.composer"（确保不被 sudo 干扰） - 每人单独运行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：必须带composer类型参数，URL 末尾必须有/） - CI 流水线里不要用
sudo composer，所有composer命令以普通用户身份执行，并显式声明cache:节点缓存vendor/和$COMPOSER_HOME/cache/ - 本地开发可设长 TTL：
composer config -g cache-files-ttl 15552000（6 个月），CI 则靠构建 key 自动轮换，不依赖 TTL
项目级镜像配置比全局更可靠
全局配置只是“方便”，但协作时它不可追踪、不可审计。真正起效且可 Git 提交的是项目级配置：
- 进项目根目录，运行：
composer config repositories.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 这条命令会自动在
composer.json的repositories下写入"packagist"条目，不破坏已有私有源 - 同时确保
"packagist.org": false出现在repositories数组第一项（否则镜像可能被绕过） - 提交
composer.json，新人克隆后composer install直接生效，无需任何手动配置
最容易被忽略的点：composer.lock 里记录的 dist URL 如果还是 https://packagist.org/，哪怕你配了镜像，Composer 在校验阶段仍可能回源——这时删掉 vendor/ 和 composer.lock，再 composer install 比调参数更干脆。
