详解Composer镜像源同步的依赖拓扑排序与下载-composer-PHP中文网

换镜像不能修正 composer update 的版本结果，因镜像仅加速元数据拉取和 zip 下载，不参与依赖求解；真正决定版本的是本地 sat 求解器，依据 composer.json 约束、minimum-stability、php 版本等条件计算得出。

详解composer镜像源同步的依赖拓扑排序与下载

composer update 为什么不能靠换镜像来“修正”版本结果

换镜像不会改变 composer update 算出来的依赖版本，它只影响元数据拉取速度和 ZIP 包下载路径。真正决定装哪个版本的，是本地 SAT 求解器根据 composer.json 的约束、minimum-stability、prefer-stable 和当前 PHP 版本等条件算出的结果。

常见错误现象：

composer update 在 A 机器装出 monolog/monolog:2.9.1，B 机器却是 3.0.0 —— 这不是镜像不同，而是两台机器的 composer.lock 不一致、PHP 版本不同、或 config.platform.php 声明不统一
换了清华源后突然装不了 dev-main 分支 —— 阿里云、华为云等部分镜像默认不同步 dev- 分支元数据，而 packagist.org 会返回；Solver 找不到匹配项，只能回退到最近 stable 版

关键点：镜像不参与求解，只提供输入数据。只要镜像同步完整且缓存已清，所有镜像源给出的 packages.json 内容一致，update 结果就该一致。

repositories 数组顺序如何实际影响依赖下载路径

Composer 查包时严格按 repositories 数组从上到下遍历，遇到第一个能返回该包元数据的仓库就停止，后续仓库完全不访问。这不是“排序”，是硬性匹配优先级。

典型配置陷阱：

私有源写在数组末尾 → Composer 先查镜像，发现无此包就报 could not find package，根本不会走到你的私有源
镜像 URL 少了末尾 / → 请求变成 https://mirrors.aliyun.com/composerpackages.json，404 后 fallback 到官方源，你以为配了镜像，其实没生效
写了 "repositories": {"internal": { ... }}（对象写法）→ Composer 只读第一个 key，其余静默丢弃，私有源形同虚设

安全写法必须是索引数组，且私有源置顶：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

"repositories": [
  {"type": "composer", "url": "https://pkgs.internal/artifactory/api/composer/internal/"},
  {"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"},
  {"packagist": true}
]

为什么 composer install --dry-run 显示 Resolving dependencies 就危险

这表示 composer.lock 已失效，install 实际会退化成 update 行为：跳过 lock 快照，重新解析依赖树并生成新版本组合。多机部署必然不一致。

触发原因通常有：

composer.json 被修改（哪怕只加了个空格），但没运行 composer update 更新 lock
本地 PHP 版本升级，导致 config.platform.php 声明与当前环境不匹配，Solver 拒绝复用 lock 中的旧决策
镜像同步延迟：新发布包在镜像中暂不可见，Composer fallback 到官方源后发现 lock 里记录的 dist URL 不再可用，强制重算

验证方式：运行 composer install --dry-run，输出必须含 Installing dependencies from lock file 才可信。否则就得人工检查 composer.lock 的 content-hash 是否与 composer.json 当前内容匹配。

parallel-downloads 和 auth.json 放哪才真正起效

parallel-downloads 是 Composer 2.2+ 的并发下载开关，默认仅 3 线程。不开它，再快的镜像也跑不满带宽。但它只对 ZIP 包下载生效，不影响元数据请求顺序或版本求解逻辑。

auth.json 的位置直接影响私有源认证成败：

必须放在项目根目录（与 composer.json 同级），或通过 COMPOSER_AUTH 环境变量注入
~/.composer/auth.json 在 CI 容器、宝塔、GitHub Actions 中基本不可用——因为 runner 用户跟 root 不是同一个家目录
私有源 URL 若含认证信息（如 https://token:x-oauth-basic@pkgs.internal/），会被 Composer 自动剥离，只认 auth.json 或环境变量

华为云、阿里云等镜像本身不需要 auth.json；但一旦项目 repositories 里混了私有源，整个认证链就必须对齐，否则 401 错误会直接中断整个安装流程。