不能只配http-proxy，因Composer对HTTP/HTTPS代理完全分离，HTTPS请求必须由https-proxy字段单独指定且值须以http://开头；漏配或格式错误会导致“Loading composer repositories”卡死。
Composer 代理配置不能只配 http-proxy，否则 HTTPS 请求必然失败——Packagist 全量走 HTTPS，而 Composer 对 HTTP 和 HTTPS 代理是完全分离的，漏掉 https-proxy 就等于没配。
为什么只设 http-proxy 还卡在 “Loading composer repositories”
现象：命令无报错、不超时、不退出，但卡住十几秒后 fallback 到直连，最终请求 https://packagist.org/packages.json 失败。
根本原因：Composer 不会用 http-proxy 去建 HTTPS 的 CONNECT 隧道；它只把 HTTP 请求发给 http-proxy，而所有 HTTPS 请求（包括 Packagist、GitHub、GitLab 等源）必须由 https-proxy 字段单独指定，且值必须是 http:// 协议开头（哪怕代理本身监听 TLS 端口）。
-
https-proxy值填成https://127.0.0.1:7890或漏协议头（如127.0.0.1:7890）→ 静默忽略，等效于未配置 - 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - Windows 下若
%APPDATA%\Composer\config.json被系统锁定，composer config -g会报 “Could not write to file”，需手动检查权限
composer config -g 配代理的正确写法
必须同时设置两个字段，且都加 -g（全局）：
composer config -g http-proxy http://127.0.0.1:7890 composer config -g https-proxy http://127.0.0.1:7890
验证是否生效，只看这一行输出：
composer config -g --list | grep -E "(http|https)-proxy"
正确结果应有两行，且 URL 格式一致。若只有一行或协议不对，说明没写进去。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI/CD 中别依赖全局配置——runner 用户家目录可能为空或不可写，改用
--repository-url+ 镜像源更可靠 - SOCKS5 代理（如 Clash TUN）需 Composer ≥ 2.2，且写法为
socks5://127.0.0.1:7891，旧版本不识别 - 取消代理用
composer config -g --unset http-proxy和composer config -g --unset https-proxy
NTLM 代理（如企业域环境）怎么破
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或连接拒绝。
唯一可行方案是引入本地中转代理工具：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128并处理 NTLM 认证 - Composer 配置指向这个本地地址：
http://127.0.0.1:3128 - 临时验证是否真卡在 NTLM：运行
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若也返回407，说明中转层没配通
别指望 HTTP_PROXY 环境变量——Composer 明确忽略它，只认自己的 http-proxy 字段。
代理配好了还是慢？先排除这三层
卡顿不是单一原因，得一层层确认：
- 本地代理进程是否真的在运行？端口是否监听？用
lsof -i :7890（macOS/Linux）或netstat -ano | findstr :7890（Windows）查 - 防火墙或安全软件是否拦截了出向连接？临时关闭测试
- 代理本身是否转发 TLS 流量？
file_get_contents(): SSL operation failed类错误大概率是证书链或隧道问题，换用http://代理可绕过
最常被忽略的是：CI 环境里既没代理也没镜像，却还硬扛 packagist.org 直连——这时候该切项目级镜像，而不是调代理。
