答案：镜像失效时composer install卡顿需先执行composer config -g repo.packagist验证，若输出为空、null或含已下线域名（如phpcomposer.com），则说明镜像不可用；正确切换命令为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并必须执行composer clear-cache后验证日志含mirrors.aliyun才生效。
镜像失效时，composer install 卡在 Resolving dependencies 或反复超时，不是网络问题，而是当前配置的镜像地址已下线或返回 404 —— 直接换源就能解决，但必须一步到位，否则仍静默走官方源。
确认当前镜像是否真的失效
别猜，先查。执行：composer config -g repo.packagist。如果输出是空、null、{"type": "composer", "url": "https://packagist.org"}，或者含 phpcomposer.com、laravel-china.org 这类域名，说明镜像已不可用（这些域名早在 2025 年底全部下线）。注意：composer config -g repos.packagist（多一个 s）不报错但完全无效，别被它骗了。
用正确命令切换到阿里云镜像
Composer 2.2+ 对参数极其敏感，三处写错任何一处都会静默失效：
-
-g参数不能漏，否则只改当前项目，换目录就还原 - 键名必须是
repo.packagist（单数repo，不是repos或packagist.org） - 命令中必须显式写出
composer作为 type 值，不能省略 - URL 必须以
https://开头，且末尾带/，例如https://mirrors.aliyun.com/composer/
正确命令是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
切完必须清缓存，否则还是走旧地址
旧缓存里的元数据（如 packages.json 校验信息）还在本地，Composer 会继续向失效镜像发请求，导致 DNS 解析卡顿或 TLS 握手失败。执行：composer clear-cache。验证是否清干净：ls -la ~/.composer/cache/ 应为空或只剩空子目录。再跑一次 composer install -vvv | grep -i "mirrors.aliyun"，日志里出现 Reading packages.json from cache at mirrors-aliyun-com-composer/ 才算真正生效。
为什么有时切了还是慢或报错？检查三层覆盖关系
Composer 查源顺序是：环境变量 > 当前项目 composer.json 中的 repositories > 全局配置。哪怕你全局配对了，只要项目里有自定义 repositories，就会被覆盖：
- 查项目是否自定义源：
grep -A 5 '"repositories"' composer.json - 查当前实际生效的源：
composer config repo.packagist（不加-g） - 检查是否有
COMPOSER_REPO_PACKAGIST环境变量干扰：env | grep COMPOSER_REPO
项目级配置优先级更高，临时调试建议用环境变量方式：COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install -vvv，退出终端即失效，不污染任何配置。
最常被忽略的是缓存清理和项目级配置覆盖 —— 两者任一没处理，换源就等于白换。
