composer.lock 文件不锁定镜像地址，只记录包的精确版本、dist url、shasum 和依赖树；镜像源配置在客户端生效，与 lock 文件无关，其作用仅限于元数据查询和 dist 包下载的透明代理，对 vcs 克隆等操作无影响。
composer.lock 文件根本不会锁定镜像地址。它只记录包的精确版本、dist URL、shasum 和依赖树，镜像源配置完全在客户端（Composer 进程）侧生效，与 lock 文件无关。
composer.lock 里实际存了什么？
打开任意 composer.lock，搜索一个包的 dist 段，你会看到类似结构：
"monolog/monolog": {
"version": "2.9.0",
"dist": {
"url": "https://api.github.com/repos/Seldaek/monolog/zipball/...",
"shasum": "a1b2c3..."
}
}
关键点：
-
url是原始 dist 地址（通常是 GitHub API、GitLab 或私有仓库），不是镜像地址 - 镜像源只是在 HTTP 请求阶段做透明代理：Composer 发起对
https://api.github.com/...的请求，但通过配置的镜像中间层转发，lock 文件对此无感知 - 如果你用的是私有 VCS 包（如
"type": "vcs"），url甚至可能是git@xxx或https://gitlab.internal/...，镜像根本不会介入
为什么改了镜像源，composer install 还是报 404 或走原站？
这不是 lock 文件“锁住”了源，而是以下任一情况在起作用：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目级
composer.json中定义了repositories字段（哪怕只是{"packagist.org": false}），会**彻底屏蔽全局镜像配置** - 镜像 URL 末尾漏了
/，例如写成https://mirrors.aliyun.com/composer→ 实际请求变成https://mirrors.aliyun.com/composerp2/xxx.json，返回 404 - CI 环境没执行
composer config -g，仍走默认packagist.org，而 lock 里写的 dist URL 又恰好被该站限流或拦截 - 你本地用
--repository临时指定了源，但 CI 脚本没同步该参数，导致行为不一致
真正影响“是否走镜像”的三个硬性条件
只有同时满足以下全部，Composer 才会把请求发往镜像：
-
composer config -g repo.packagist输出是有效的镜像 URL（含末尾/） - 项目
composer.json中没有repositories字段，或明确启用了 packagist.org（"packagist.org": true） - 请求的目标是元数据（如
packages.json）或 dist 包（如vendor/package/version.zip），而非 VCS 克隆（git clone）
一旦涉及 git 协议或自定义 VCS 源，镜像就完全不参与——这是设计使然，不是 bug，也不是 lock 文件能干预的。
容易被忽略的静默失效点
最常被忽视的是：即使你全局配了镜像，只要 composer.json 里出现空 "repositories": [] 或 "repositories": {}，Composer 就会认为“你主动接管了源管理”，立刻丢弃所有全局镜像设置。这种失效没有警告，也没有日志提示，只会表现为请求变慢、超时或 404 —— 它看起来像 lock 文件“锁死了地址”，其实只是配置被悄悄覆盖了。
