换镜像后“报错更快”是因为镜像仅加速元数据下载，不改变SAT求解逻辑；卡在“Resolving dependencies through SAT”本质是约束过宽、dev分支混用或conflict冲突等硬伤，需用composer clear-cache、composer config -g repo.packagist验证镜像、composer why-not精准定位阻断源。
composer update 卡在 “Resolving dependencies through SAT” 不是镜像慢，是约束逻辑太松或环境不一致导致求解器反复试错。换镜像只能让报错更快，不能跳过冲突检测本身。
为什么换镜像后“报错更快”，但问题还在？
镜像只加速元数据（packages.json、provider-*.json）下载，不影响 Composer 内部的 SAT 求解过程。阿里云、腾讯云镜像把元数据拉得快，composer why-not 响应从 2 分钟缩到 1 秒，但这只是暴露了你本就存在的约束矛盾。
常见误判：
- 看到报错变快，以为“解决了”，其实只是更快告诉你
Conclusion: Your requirements could not be resolved - 把
conflict字段或platform版本不匹配当成网络问题去换源
真正拖慢依赖解析的三类硬伤
这些和镜像无关，必须人工干预： -php 平台声明太宽泛：比如 "php": ">=7.4" 会让求解器遍历几百个历史版本；收紧为 "php": "^8.1" 可减少 80%+ 组合空间
- 项目里混用 dev-main 和稳定版：某个私有包刚推了 dev-main，其 composer.json 里悄悄加了 "require": {"monolog/monolog": "^3.0"}，而主项目锁的是 ^2.0 → 冲突立刻触发
- conflict 字段显式拦截：例如 "spatie/laravel-backup": "7.0.0" 自带 "conflict": {"laravel/framework": ">=11.0"}，哪怕你没装 L11，只要某依赖间接拉入 L11，求解器就会失败
用 composer why-not 定位真实拦路虎
这是唯一能快速定位冲突源头的命令，但需配合镜像 + 清缓存才准：
- 先执行 composer clear-cache：防止本地缓存旧元数据误导判断
- 确保镜像配置正确：composer config -g repo.packagist 输出必须是 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意末尾斜杠）
- 运行 composer why-not vendor/package:version，例如 composer why-not laravel/framework:11.0
- 如果输出为空，不是镜像问题，而是你根本没在 composer.json 里声明该包，或版本号写成 11 而非 11.0CI/CD 中突然构建失败？大概率是镜像暴露了长期被忽略的问题
本地开发可能一直用着过期的composer.lock 或缓存元数据，而 CI 使用新镜像拉到了最新约束。此时：
- 别急着切回官方源，先跑 composer update --dry-run -vvv 看具体哪条约束被触发
- 检查 config.platform.php 是否与实际运行环境一致（比如 CI 是 PHP 8.3，但 composer.json 里写了 "platform": {"php": "8.1"}）
- 若必须兼容旧环境，用 composer update --with-all-dependencies 临时绕过子依赖校验（仅限 CI，勿提交 lock 文件）
镜像本身不会让依赖解析变快，但它能让“哪里错了”这件事变得清晰——而这恰恰是最容易被跳过的一步。
