卡在“loading composer repositories”是镜像未生效，需确保repo.packagist键名正确、显式指定type为composer、url以/结尾且执行clear-cache；卡在“resolving dependencies”则是本地sat求解瓶颈，与镜像无关，须收紧版本约束、禁用xdebug、提升php版本并复用composer.lock。
Composer 导出（composer install 或 composer update 后生成 composer.lock）本身不“慢”，但你卡在导出前的环节——比如 Resolving dependencies、Loading composer repositories 或反复 Downloading——那根本不是导出问题，而是元数据拉取和依赖求解被阻塞了。
为什么 composer install 卡在 Loading composer repositories
这是 Composer 启动时拉取 packages.json 元数据的第一步，90% 的失败源于镜像配置未真正生效：
-
repo.packagist键名写成repos.packagist（多一个 s），命令静默忽略，仍走https://packagist.org - 漏掉
composer这个 type 参数：composer config -g repo.packagist https://mirrors.aliyun.com/composer/❌，必须写成composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅ - URL 少了末尾斜杠：
https://mirrors.aliyun.com/composer会拼成/composerpackages.json，返回 404 - 没清缓存：
composer clear-cache没执行，它还在读旧的官方源元数据
验证是否生效：运行 composer config -g repo.packagist，输出必须是完整 JSON，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或仍是 packagist.org 都说明没配进去。
Resolving dependencies 耗时超 2 分钟？镜像完全没用
这个阶段纯本地计算，不发任何网络请求。镜像再快也救不了它。常见诱因是版本约束太宽：
-
"php": "^7.4 || ^8.0"让求解器遍历所有兼容组合，复杂度指数增长 -
"minimum-stability": "dev"强制加载所有 dev 分支的元数据（哪怕你没声明） - 依赖中混用
*、^1.0 || ^2.0、dev-master等模糊写法
解决方法不是换源，而是收紧约束：删掉 minimum-stability，把 * 换成具体版本（如 "monolog/monolog": "2.13.0"），再跑 composer update --with-dependencies 观察耗时变化。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
全局镜像对 composer global require 失效？查用户权限
composer global require 完全不读项目目录下的配置，只认 ~/.composer/config.json。但很多环境实际运行用户 ≠ 你配镜像的用户：
- 宝塔「一键部署」以
www用户运行，你在终端用 root 配的镜像，www根本读不到 - CI 脚本里用
sudo composer config -g，写进了/root/.composer/config.json，而构建容器里跑的是runner用户 - PHP 禁用了
putenv()（见php.ini中disable_functions），导致config -g写配置失败却不报错
实测方法：在目标环境下直接执行 composer config -g repo.packagist，并用 composer global require monolog/monolog -vvv 2>&1 | grep "packages.json" 看实际请求 URL 是否命中镜像域名。
composer install 还是慢？别只盯镜像
换源只是基础，以下三点常被忽略却直接影响最终耗时：
- 没启用
--prefer-dist：默认可能走git clone，比下载 ZIP 包慢 3–5 倍；生产环境必须加 - 没加
--no-dev：Laravel 等框架的 dev 依赖（如phpunit/phpunit）占包数量 40%+，部署时完全不需要 - Xdebug 开着：运行
php -v看是否含xdebug，有就临时禁用——依赖解析阶段会慢 5–10 倍
最易被忽略的点：composer.lock 文件若来自其他环境（比如 CI 生成后手动拷贝），可能含已下线包的 hash，触发回退查找；建议在目标机器上删掉 vendor/ 和 composer.lock，用 composer install --no-cache 重装。
