Composer下载慢90%因直连packagist.org导致DNS解析慢、TLS握手卡、首字节延迟高甚至超时；必须全局配置阿里云镜像源（composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/），严格满足键名、type值、URL末尾斜杠三要素，并执行composer clear-cache及-vvv验证日志中出现镜像域名才算生效。
Composer网络响应时间过长，90%不是本地网速问题，而是仍在直连packagist.org——DNS解析慢、TLS握手卡、首字节延迟高，甚至直接超时。换镜像不是“可选项”，是必须立即执行的前置动作。
确认当前用的是哪个源（别信 config 输出）
运行composer config -g repo.packagist只看输出是否为完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空值、null、或仍是https://packagist.org，说明配置根本没写进去。
- 常见静默失败原因：键名写成
repos.packagist（多一个 s）、漏掉中间的composertype 值、URL 末尾缺/ - 项目级
composer.json里有repositories字段，会直接覆盖全局配置；可用composer config --list和composer config --list --global对比确认实际生效项 - 宝塔、CI 或计划任务常以
www用户运行，但composer config -g默认写入/root/.composer/config.json，www用户读不到；应切用户执行：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
换源后仍卡在 Resolving dependencies 或 Downloading？清缓存是硬要求
composer clear-cache不是“建议步骤”，是必须执行的操作。旧缓存里存着packagist.org的packages.json和元数据，Composer 会优先读缓存并尝试从旧地址拉取校验信息——结果就是卡在 DNS 解析或 TLS 握手，压根没发请求到新镜像。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证是否真走镜像：加
-vvv跑命令，例如composer install -vvv 2>&1 | grep "Downloading"，日志中必须出现mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn才算生效 - 如果项目已有
composer.lock，它记录的是旧源的包哈希，和镜像返回的元数据不兼容，大概率报hash does not match；建议删掉vendor/和composer.lock再重装 - 临时绕过所有自定义源测试：
composer install --no-plugins --repository=https://packagist.org，如果变快，说明本地repositories配置有问题
Resolving dependencies 卡住 ≠ 网络问题，别白换镜像
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。尤其当你写了"*"、"^1.0 || ^2.0"或"minimum-stability": "dev"时，求解器会指数级爆炸。
- 检查
composer.json里是否有宽泛约束，改用更精确的版本号，比如"monolog/monolog": "^2.10"而非"^2.0" -
composer update比install更易卡在此阶段；如非必要，避免在 CI 中运行update，优先用install复用composer.lock - 启用
COMPOSER_DISABLE_XDEBUG_WARN=1环境变量可避免 Xdebug 拖慢依赖求解（尤其 PHP 8+）
并发与超时参数要配对设，单设无效
Composer 2.2+ 已弃用parallel-downloads，只认http-max-concurrent-downloads。但只调高并发不加大超时，反而容易触发连接中断。
- 推荐组合设置：
composer config -g http-max-concurrent-downloads 10+composer config -g http.timeout 300+composer config -g process-timeout 3600 -
http-max-concurrent-downloads只对install有效，对update几乎无加速作用——依赖图计算本身是串行的 - 设成 20 容易触发临时文件竞争或镜像限流；实测 8–10 是稳定平衡点
最常被忽略的其实是缓存路径权限和composer.lock的源绑定关系——换镜像后不删锁文件、不清缓存、不切用户，等于什么都没做。
