直接换源仅解决90%安装慢问题，关键在正确配置repo.packagist、清空缓存及区分项目级与全局优先级；执行composer config -g repo.packagist应输出完整JSON，否则配置无效；缓存不清会导致仍走官方源；项目级配置更可靠；卡在“Resolving dependencies”与镜像无关，实为依赖约束或环境问题。
直接换源就能解决 90% 的 Composer 安装慢问题，但真正生效的关键不在“选哪家镜像”，而在于 repo.packagist 配置是否写对、缓存是否清干净、以及项目级与全局配置的优先级是否被误判。
怎么确认当前生效的镜像源是哪个
执行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、Key "repo.packagist" does not exist，或者还是 https://packagist.org，说明配置根本没写进去。
- 常见错误：把
repo.packagist写成repos.packagist（多一个 s），Composer 会静默写入无效字段，不报错也不提示 -
-g参数不能省——漏掉就只改当前目录的composer.json，换个项目立即失效 - 项目根目录下运行
composer config repo.packagist（不带-g）看到的是项目级配置，不代表全局生效，别混淆
为什么清缓存这一步不能跳过
缓存里存着旧的 packages.json 和 provider 元数据，Composer 会优先读本地缓存再校验远程地址——哪怕你已经切了镜像，它仍可能反复尝试从 https://packagist.org 拉取索引，卡在 DNS 解析或 TLS 握手阶段。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须用
composer clear-cache（不是composer cache-clear，后者已废弃） - 验证是否清干净：检查
~/.composer/cache/目录是否为空，或临时加--no-cache跑一次composer install -vvv，看日志里请求的是哪个域名 - 改完镜像后不清理缓存，大概率继续走官方源，且无任何警告
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置写在 ~/.composer/config.json，但「谁在跑命令」决定读哪个文件。宝塔后台以 www 用户运行、CI 流水线用 runner 用户、Docker 容器里可能是 app 用户——composer config -g 很可能配到了错误用户的家目录下。
- 推荐做法：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 这条命令会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源（前提是原repositories是对象结构而非数组） - 改完记得删掉
vendor和composer.lock，否则旧 lock 文件里的 hash 可能和镜像元数据不匹配，导致Signature mismatch
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速下载环节，不参与依赖解析。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是本地约束问题：
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"，会让求解器尝试所有组合 -
require-dev里塞了太多工具链（如phpunit、larastan、pestphp/pest），尤其当它们之间存在版本冲突时 - 用了模糊版本号，如
"monolog/monolog": "*"或"^1.0"，而不是锁死小版本或提交 hash - 启用了已废弃的
fxp/composer-asset-plugin（常见于老版 Yii2 项目），它不走 Composer 镜像配置，还会额外请求 Bower/NPM 源
最常被忽略的一点：换源只是把元数据和 ZIP 包的下载节点换了，但 composer.json 里的约束逻辑、PHP 环境、Xdebug 是否启用、以及是否禁用了 packagist.org 回退机制，这些才真正决定解析快慢。别让“镜像已配好”的错觉掩盖了真实的约束膨胀问题。
