根本原因是composer不读系统http_proxy环境变量，必须同时配置http-proxy和https-proxy两个字段，漏配任一将导致https请求静默直连超时；且需验证composer config -g --list输出含两行正确格式代理地址。
为什么配了代理，composer install 还卡在 Loading composer repositories
根本原因是 Composer 不读系统 HTTP_PROXY 环境变量，且必须同时配置 http-proxy 和 https-proxy 两个字段——漏掉任意一个，HTTPS 请求（包括所有 Packagist 和 GitHub 流量）就会静默 fallback 到直连，最终超时或卡住。
常见错误现象：
-
https-proxy值写成https://127.0.0.1:8080（协议必须是http://，哪怕代理本身支持 TLS） - 只执行
composer config repo.packagist ...，没加-g，结果只写入当前项目，换目录就失效 - 公司用 NTLM 代理（如 Windows 域环境），Composer 原生不支持，必须用
cntlm或px中转到本地127.0.0.1:3128
验证是否生效的最简方式：composer config -g --list | grep -E "(http|https)-proxy"
输出里必须有两行，且 URL 格式正确（http://user:pass@127.0.0.1:8080，密码含 @ 或 / 需 rawurlencode）。
repo.packagist.org.proxy 和全局 https-proxy 有什么区别？
两者作用范围和优先级不同，不是互斥关系：
-
https-proxy是全局隧道代理，影响所有 HTTPS 请求（包括 GitHub API、codeload.github.com、私有仓库等） -
repo.packagist.org.proxy是仓库级代理，只对packagist.org元数据请求生效，不影响 ZIP 下载；它支持socks5://（需 Composer ≥ 2.2），但不处理 TLS 握手失败 - 如果同时配置，
repo.packagist.org.proxy优先级更高，但仅限该域名；其他 HTTPS 请求仍走https-proxy
典型误用场景：只配 repo.packagist.org.proxy，却没配 https-proxy，导致 codeload.github.com 下载仍卡死——因为 ZIP 包下载不走这个仓库代理。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
代理配好了，但下载速度还是 0 B/s，怎么定位瓶颈？
不能只看终端是否滚动，要分层验证：
- 元数据层（
packages.json）：运行curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.aliyun.com/composer/packages.json，中位数 > 1.5s 说明 TLS 握手或反向代理链路有问题 - ZIP 层（
provider-*.json或 dist）：用curl -r 0-1048575 -o /dev/null -s -w "%{speed_download}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/provider-laravel~framework.json， - 日志层：必须
composer install -vvv 2>&1 | grep "Downloading"，确认是否真出现ghproxy.com或镜像域名；若夹杂codeload.github.com，说明composer.lock没删干净
特别注意：composer update --lock 不会刷新 dist.url，必须 rm -rf vendor composer.lock && composer install 才能强制重写所有下载地址。
CI 环境下代理和缓存怎么配合才不翻车？
CI 容器生命周期短，缓存路径错配是高频故障点：
-
cache-dir必须挂载到高速本地盘（如 SSD），不能指向 NFS 或 Docker volume；推荐显式设为/tmp/composer-cache - CI 脚本里别用
sudo composer config -g，否则写进 root 配置，普通用户 runner 读不到 - 缓存路径要精确到
~/.composer/cache/files（存放 ZIP 的地方），只缓存vendor/或顶层~/.composer/cache都无效 - 必须搭配参数：
composer install --no-dev --prefer-dist --optimize-autoloader，缺一不可；否则缓存利用率极低
最易被忽略的一点：GitHub OAuth token 要提前注入（composer config -g github-oauth.github.com <token></token>），否则 CI 中大量 API 请求会被限速，代理也救不了。
