镜像源仅加速下载，不参与版本求解；依赖版本由composer.json约束、platform配置及composer.lock快照共同决定，换源不会改变版本结果。
为什么镜像源本身不能统一依赖版本
镜像源（比如 https://mirrors.aliyun.com/composer/）只加速包下载，不参与版本求解。它只是把 packagist.org 的内容做了一层缓存代理，composer install 或 composer update 时真正决定装哪个版本的，是 composer.json 的约束 + 当前平台环境 + composer.lock 的快照。换镜像不会让 monolog/monolog 从 2.9.1 变成 3.0.0，也不会修复因 PHP 版本不一致导致的 lock 解析差异。
常见错误现象：
- 团队成员都配了阿里云镜像，但本地
composer install装出的guzzlehttp/guzzle版本和 CI 不一样 - 有人在全局
~/.composer/config.json里写了镜像，又在项目里写了另一个，结果部分包走全局、部分走项目，行为不可预测
必须用项目级 config 锁定镜像，禁用全局配置
项目根目录的 composer.json 必须显式声明 repositories 和 config，否则镜像配置就不是“项目契约”，而是“个人偏好”。只要有一人没清掉全局配置，协作就存在隐性分歧。
实操建议：
- 在
composer.json中写死镜像源，例如："repositories": { "packagist.org": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } } - 提醒所有人执行
composer config --global --unset repos.packagist清除全局镜像设置 - 检查是否残留：运行
composer config --global repo.packagist，输出应为空或https://packagist.org（即恢复默认） - CI 脚本开头加一句
composer config --global --unset repos.packagist，防止单独配置污染
镜像只是加速手段，真正起作用的是 lock 文件 + platform 约束
多机协同能否一致，80% 取决于 composer.lock 是否提交、是否被所有机器严格遵守；剩下 20% 是 config.platform 是否显式声明了团队统一的 PHP 和扩展版本。镜像再快，如果 lock 里记录的是基于 PHP 8.2 解出的依赖，而某台机器是 PHP 8.1，composer install 就会失败或跳过某些包。
关键配置示例（放在 composer.json 的 config 下）：
"platform": {
"php": "8.1.10",
"ext-zip": "8.1.10",
"ext-mbstring": "8.1.10"
}
注意点：
-
platform.php必须写到小版本号（如"8.1.10"），写"8.1"或"^8.1"会被 Composer 忽略 - 改完
platform后，必须删掉vendor/和composer.lock，再跑composer install才会生效 - 验证是否起效：运行
composer show php，输出的 version 应与配置完全一致
Docker 构建中镜像源和 lock 的配合顺序
在 Dockerfile 里用镜像源，不是为了“让容器更快”，而是为了防止构建时因网络抖动或 packagist 宕机导致失败。但前提是：镜像源配置必须和 composer.lock 同步，且构建命令必须是 composer install。
错误写法：
RUN composer update -n && composer dump-autoload—— 这等于放弃 lock，每次构建都重算依赖
正确流程（片段）：
FROM php:8.1-fpm WORKDIR /app COPY composer.json composer.lock ./ # 镜像源配置必须在 install 前就位，所以先 COPY，再 RUN RUN composer config --global repos.packagist composer https://mirrors.aliyun.com/composer/ \ && composer install --no-dev --no-scripts --no-autoloader \ && composer dump-autoload --optimize
要点：
-
composer.lock必须COPY进镜像，不能靠RUN composer update生成 - 不要在
RUN行里混用config --global和install，Docker 层缓存可能导致 config 生效滞后 - CI 构建中若用
--no-cache，要确保镜像源配置仍能命中，否则 fallback 到 packagist.org 可能超时
真正的难点不在配镜像，而在于所有人是否真的只碰 composer install，以及是否敢删掉自己本地的 vendor/ 和 composer.lock，然后老老实实重新拉一次。一旦有人图省事 composer update --lock 后不提交，或者手动改 composer.json 后忘了 update，整套机制就从根上松动了。
