不能共享 ~/.composer/cache，因会导致哈希校验失败（php/扩展版本差异致同一zip校验不一致）、auth.json凭证泄露（token属个人敏感信息）、vendor/bin软链接断裂（路径绑定用户环境）；/etc/composer/config.json才是唯一真正全局生效路径，但需满足目录权限、路径精确、键名严格及url规范四条件；项目级composer.json配置为跨环境兜底方案，须确保repositories为顶层对象、键名为packagist、含type和带/的https url，并配合composer update --lock更新lock文件以同步dist.url。
为什么不能直接共享 ~/.composer/cache
共享缓存目录会导致哈希校验失败、软链接断裂、凭证泄露三类硬性错误。同一份 cache/ 下的 zip 包在 A 机上校验通过，B 机上可能报 Hash mismatch；auth.json 里存的是个人 token，共享等于公开私钥；vendor/bin 软链接指向各自安装路径，共享后直接失效。这不是性能问题，是根本不可用。
/etc/composer/config.json 是唯一真正全局生效的路径
它不依赖用户 HOME，所有 PHP 进程（包括 www-data、CI runner）都会读取。但必须同时满足四个条件：
-
/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，输出应为镜像地址。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
项目级 composer.json 配置才是跨环境兜底方案
即使系统级配置下发失败，只要 composer.json 里有正确结构，就能强制走镜像。但注意写法细节：
-
"repositories"必须是顶层字段，值为对象（不是数组） - 键名必须是
"packagist"（不是"packagist.org"或"aliyun"） - 内容格式为：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 确保
"packagist.org": false出现在repositories数组第一项，否则镜像可能被绕过
执行命令：composer config repositories.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），它会安全写入，不破坏已有私有源。
composer.lock 里的 dist.url 容易被忽略
即使镜像配置全部正确，composer.lock 中已锁定的包仍可能保留旧的 dist.url（比如 https://packagist.org/...）。下次 install 时 Composer 会直接下载该 URL，绕过所有镜像设置。解决办法只有重新生成 lock 文件：composer update --lock 或删掉 composer.lock 后再 composer install。团队协作时，这条必须纳入 PR 检查清单。
