多分支开发下镜像配置失效的根本原因是分支间composer.json和composer.lock状态不一致：主干分支可能已生成适配镜像的lock文件，而feature分支仍沿用记录原始dist.url和hash的旧lock，导致install时按旧路径请求镜像却404或校验失败；同时各分支repositories字段格式不统一、CI未提交lock、全局配置不可控，进一步加剧不一致。

为什么多分支开发下镜像配置容易失效

不是镜像地址变了，是分支间composer.json和composer.lock状态不一致导致的。主干分支可能已配好镜像并生成了适配新源的composer.lock，但 feature 分支仍沿用旧 lock 文件——它记录的是 packagist.org 的 dist URL 和 hash，换镜像后 Composer 仍按原路径去阿里云拉包，结果 404 或 hash 不匹配。

• 老分支没删过 vendor/ 和 composer.lock，执行 composer install 时完全跳过元数据解析，直接照搬 lock 里的旧下载地址
• 不同分支的 composer.json 中 repositories 字段结构可能不统一：有的写成对象 {"packagist.org": false}，有的是数组 [{"type": "composer", "url": "..."}]，Composer 解析逻辑不同
• CI 流水线拉取分支时默认不带 composer.lock（.gitignore 常忽略它），导致每次都是从头 resolve，而 resolve 阶段又依赖全局或项目级镜像配置是否生效

如何让每个分支自动用对镜像

靠命令行临时切换不现实，必须把镜像声明固化进版本控制，并确保 lock 文件与之同步。关键不是“配一次”，而是“每次 checkout 后能自洽”。

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 字段，且格式统一为数组：

  "repositories": [
    {"packagist.org": false},
    {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
  ]

  第一项禁用兜底，第二项指定镜像，顺序不能颠倒
• 禁止使用 composer config -g 全局配置——CI 环境用户不可控，且 feature 分支开发者本地可能没配，行为不一致
• CI 脚本中强制加一步：rm -rf vendor composer.lock && composer install --no-interaction，确保每次构建都基于当前分支的 composer.json 重新生成 lock
• Git 提交前运行 composer update --lock（非 install），只更新 lock 文件不改 vendor，避免引入意外依赖变更

feature 分支合并前必须检查的三件事

合并不是按 Git 提交顺序走，而是按 Composer 锁文件兼容性走。漏检一项，合进去就炸。

• 对比 composer.lock 的 content-hash：老分支是 32 位 md5，新分支应是 64 位 sha256；若不一致，说明 lock 文件未按当前镜像重新生成
• 检查 composer.lock 里每个包的 dist.url 是否都指向镜像域名（如 https://mirrors.aliyun.com/composer/dist/...），而不是 https://api.github.com/ 或 https://packagist.org/
• 运行 composer show symfony/console（选一个核心包），确认输出的 versions 列表中实际安装版本与 lock 文件记录一致；若显示 Could not find package，说明镜像源没覆盖到该版本（常见于 PHP 7.4 项目依赖的 v3.x 包）

私有包 + 镜像混用时的分支陷阱

当项目同时引用私有 Git 仓库和公共镜像时，分支切换容易触发源冲突——不是网络问题，是 Composer 对 repositories 数组的合并策略在不同版本间有差异。

• Composer 2.2+ 默认启用隐式 packagist.org 兜底，但如果你在某个分支里写了 "repositories": [{"type": "vcs", "url": "git@xxx"}] 却没显式禁用官方源，Composer 会先查私有源，再查 packagist.org，最后才走镜像——而镜像根本不在这个 fallback 链里
• 正确写法是在所有分支的 composer.json 里固定写死：

  "repositories": [
    {"packagist.org": false},
    {"type": "vcs", "url": "git@xxx"},
    {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
  ]

  顺序决定优先级：私有源第一，镜像第二，官方源彻底关闭
• 切分支后如果发现 composer install 报 Could not find package xxx，先运行 composer clear-cache，再删 composer.lock ——缓存里可能残留旧分支的元数据索引

真正麻烦的从来不是配镜像，是让不同分支在不同时间点、不同环境里，始终用同一套源规则解析同一份依赖树。锁文件、源声明、缓存三者必须严格对齐，缺一不可。