Composer依赖解析与镜像拉取完全独立：前者是纯内存SAT求解，仅读composer.json、缓存元数据和composer.lock，不发网络请求；后者仅在版本确定后下载包。换镜像无法解决冲突，只能加速暴露问题。
Composer 的依赖解析和镜像拉取是两个完全独立的阶段，前者纯逻辑求解、后者纯网络下载；混淆这两者，是绝大多数“换镜像就能解决依赖冲突”误解的根源。
composer update 失败根本不是网络问题
当你看到 Your requirements could not be resolved 或 can only install one of 这类错误，说明 SAT 求解器已经穷尽所有可能组合并证明无解——此时连 DNS 查询都没触发，更别说访问镜像了。求解过程发生在内存中，只读 composer.json、已缓存的元数据（如 packages.json）、以及本地 composer.lock（如有），不发任何 HTTP 请求。
- 换阿里云/腾讯云镜像、改
repo.packagist配置、甚至关掉网络，只要元数据缓存还在，错误一模一样 -
--ignore-platform-reqs和--no-cache也绕不过这个阶段：前者跳过 PHP 版本校验，后者只清空下载缓存，不影响规则生成和求解 - 真正影响求解结果的，只有
require/conflict声明、platform配置、以及composer.lock是否存在及其内容
镜像只在下载阶段起作用，且必须全局配置才生效
镜像只参与「已确定要安装哪些包 + 哪些版本」之后的下载环节。但很多人配错，导致镜像形同虚设：
- 必须用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/——漏掉-g就只对当前目录有效；URL 末尾斜杠不能少，否则静默失效 -
composer.json里写"repositories"数组对 Packagist 官方源无效，它只用于私有源；全局镜像配置优先级高于项目级配置 - 验证是否生效：运行
composer config repo.packagist，输出 URL 必须含镜像域名；再执行composer show packagist/support，看source.url字段是否指向镜像
SAT 求解器卡住或爆内存的典型诱因
求解本身是 NP 完全问题，以下情况会让 Composer 在解析阶段明显变慢甚至 OOM：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"monolog/monolog": "*"这类宽泛约束，把成百个历史版本全纳入变量空间，指数级膨胀搜索树 - 多个包互相
conflict但没显式排除，求解器需反复回溯验证冲突路径，耗时陡增 -
composer update --with-all-dependencies却没加--no-dev，把require-dev里的测试工具也拖进全局求解，变量数翻倍 - PHP
memory_limit设置过低（尤其 CI 环境），默认 128M 在大型项目中常不够用
实操建议：composer update --dry-run -v 可观察求解器实际尝试了哪些包；收紧约束（如把 * 改为 ^2.9）比换镜像管用得多。
循环依赖报错与镜像完全无关
循环依赖（如 A → B → A）在依赖图构建阶段就被检测并终止，根本不会生成任何下载任务。镜像哪怕配置成 https://nonexistent-mirror.com，错误信息也毫无区别。
所谓“换镜像后不报错了”，通常是以下原因：
- 旧镜像缓存了缺失
conflict字段的过期元数据，导致求解器误判可解；新镜像同步完整，反而暴露真实冲突 -
composer.lock记录的是旧解析结果，换镜像后composer update触发重算，恰好因config.platform.php变化让某条隐式路径被跳过 - 不同镜像返回的可用版本列表略有差异，偶然避开了某个引发闭环的具体版本（不可靠，非解决）
真正的解法永远是重构依赖关系，比如抽离公共接口到独立包，而不是指望镜像“修复”逻辑矛盾。
