不能共享 Composer 缓存镜像，因 auth.json 凭证泄露、config.json 环境差异、cache/ 哈希校验失败及 vendor/bin 软链接断裂等问题会导致直接失败；应统一镜像配置并各自维护独立缓存。
不能为不同团队“定制”同一个 Composer 镜像配置，因为镜像源本身是全局服务（如 https://mirrors.aliyun.com/composer/），不区分团队；真正需要差异化的是**配置落地方式、生效范围和权限归属**——否则轻则失效，重则泄露 token 或导致 Hash mismatch。
为什么不能用统一 COMPOSER_HOME 目录共享配置
所有试图让多个用户共用 ~/.composer 或统一 COMPOSER_HOME 的做法都会失败，不是慢，而是直接中断：
-
auth.json里存的是个人私有仓库 token，共享等于把凭证明文分发出去 -
config.json中的 proxy、镜像地址、cache-dir路径等，每个成员网络环境不同，硬统一会连不上 -
cache/下的 zip 包哈希值依赖 PHP 版本、openssl版本甚至glibc小版本，A 机缓存 B 机加载必报Hash mismatch -
vendor/bin/里的全局命令（如laravel）是软链接，指向各自安装路径，共享会导致链接断裂或覆盖
团队级配置必须走 /etc/composer/config.json（非用户家目录）
当你需要让 PHP 运行用户（如 www-data、nginx、CI runner）也生效时，composer config -g 完全无效——它只写进当前用户的 ~/.composer/config.json，而 Web 服务根本读不到。
唯一真正全局生效的路径是：/etc/composer/config.json，但必须同时满足四个硬性条件：
-
/etc/composer/目录存在，权限为755，属主root:root - 文件路径必须严格是
/etc/composer/config.json（不能是/etc/composer.json） -
"repositories"必须是对象（不是数组），键名严格为"packagist.org" -
"url"值必须是 HTTPS 且末尾带/，例如："https://mirrors.aliyun.com/composer/"
验证是否生效：切换到真实运行用户执行 sudo -u www-data composer config repo.packagist，输出应为镜像 URL。
项目级配置才是跨团队协作的唯一可靠方案
只要项目根目录下有 composer.json 并含 repositories 字段，全局配置就会被完全忽略——你配了也没用。所以跨团队协作必须把镜像源写进 composer.json，并提交 Git：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不破坏已有私有源 - 必须显式添加
"packagist.org": false到composer.json根节点（不是repositories里），否则仍可能 fallback - 首次切镜像后，必须删掉
vendor/和composer.lock，再跑composer install——否则composer.lock里dist.url还是直连 GitHub
最容易被忽略的点：dist.url 不走镜像
镜像只托管元数据（packages.json），不托管实际 ZIP 包。如果 composer.lock 里 dist.url 还是 https://api.github.com/，Composer 就绕过镜像直连——哪怕你配置全对，下载阶段依然卡在 GitHub。
这意味着：每次切换镜像源，或团队新成员首次拉代码，都必须清空 vendor/ 和 composer.lock，再执行 composer install，否则旧 lock 文件里的 dist URL 不会自动更新。
