项目级镜像配置仅覆盖全局设置且不改变vendor目录结构，只影响包下载地址和元数据路径，不会触发vendor重建、autoload重生成或composer.json拆分。
项目级镜像配置会覆盖全局设置，但不改变vendor目录结构
镜像源只影响包下载地址和元数据请求路径，不会触发 vendor 目录重建、autoload 重生成或 composer.json 拆分。哪怕你把阿里云镜像写进 composer.json 的 repositories，vendor/ 里装的仍是同一套包——只是从国内 CDN 拉的 ZIP 而已。
容易踩的坑：
- 误以为配了镜像就能“自动拆服务”：镜像和微服务拆分毫无关系，
composer.json还是那个单体文件，autoload还是全局映射 - 改完镜像后跑
composer install却发现vendor/没更新：因为composer.lock里记录的是旧 source URL，必须删掉composer.lock和vendor/后重装才生效 - 在 CI 中用
--repository-url临时切镜像，结果本地composer.lock生成了镜像域名的 dist URL，导致线下环境拉不到包
镜像同步延迟可能让 composer update 行为不可预期
镜像不是实时快照，而是分片 + 延迟同步的索引结构。你写了 "monolog/monolog": "^2.9"，但镜像还没同步 v2.9.5 tag，composer update 就会退回到 v2.9.4 —— 不报错，也不提示，只默默降级。
这直接影响项目重构时的版本控制：
- 你想用新 API（比如
Monolog\Handler\SlackHandler新增的setUsername()）但实际装的是旧版，运行时报Call to undefined method - 私有包打了个
v1.3.0tag，镜像没抓到，composer require vendor/pkg:1.3.0直接失败，而你查 GitHub release 页面明明存在 -
composer show -a monolog/monolog显示的可用版本，反映的是当前镜像所见，不是 Packagist 全量；别拿它当权威依据
重构项目时若移动 vendor 目录，镜像配置完全无关
镜像源和 vendor 存放位置是两条平行线。你用 COMPOSER_VENDOR_DIR=lib/vendor 把依赖装到 lib/vendor，镜像还是从 https://mirrors.aliyun.com/composer/ 下载 ZIP，只是解压目标变了。
真正要操心的是路径硬编码问题：
-
vendor/autoload.php里写的全是相对路径，挪动后不会自适应，必须靠COMPOSER_VENDOR_DIR环境变量驱动整个流程 - 代码里写死的
require 'vendor/autoload.php'必须同步改成require 'lib/vendor/autoload.php' - IDE 或 Web 服务器不会自动识别新路径，需手动配置 autoload root 或修改部署脚本
跨服务重构时，镜像无法解决私有包认证与仓库配置冲突
当你把单体拆成 user-service 和 order-service，每个服务都有自己的 composer.json，镜像只管 public 包下载。私有 DTO 包（如 acme/shared-dto）仍需手动配 repositories 和 auth.json。
常见翻车点：
- 在
user-service/composer.json里写了腾讯云镜像，在order-service/composer.json里写了阿里云镜像——两者互不干扰，但团队成员容易混淆哪边该走哪个源 - 私有 Git 仓库用了 SSH URL（
git@github.com:acme/shared-dto.git），CI 环境却只配了 HTTP Basic 认证，composer install直接卡在克隆阶段 -
auth.json放在项目根目录下，但 Docker 构建时没 COPY 进去，导致构建失败且错误信息只显示 “Could not fetch”，看不出是认证问题
