Composer代理配置必须同时满足清空镜像、配齐http-proxy和https-proxy、URL协议头写对三个硬性条件，缺一则install会卡在Loading composer repositories且不报错；因Packagist全量走HTTPS，仅配http-proxy无效，https-proxy值须以http://开头且含正确编码的认证信息，且需先执行composer config -g --unset repo.packagist确保镜像已清空。
Composer 代理配置不是“设了就能用”，而是必须同时满足三个硬性条件：清空镜像、配齐 http-proxy 和 https-proxy、URL 协议头写对；漏掉任一，composer install 就会卡在 Loading composer repositories 且不报错。
为什么只配 http-proxy 还是连不上 Packagist
Packagist 全量走 HTTPS，而 http-proxy 只处理 HTTP 请求；HTTPS 请求必须由 https-proxy 字段触发 CONNECT 隧道，否则 Composer 会 fallback 直连——结果就是超时、静默失败或 cURL error 35。
-
https-proxy的值必须以http://开头（哪怕代理监听的是 TLS 端口），填https://或漏协议头都会失效 - 用户名/密码含
@、/、:时，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - 命令必须加
-g（全局），否则只写入当前项目，换目录就丢失
配代理前必须先清空镜像源
镜像和代理互斥：一旦设置了 repo.packagist，Composer 就完全忽略 http-proxy 和 https-proxy 字段。国内用户卡住，90% 是因为两者混配。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer config -g --unset repo.packagist（注意不是repos.packagist或packagist.org） - 验证是否清空：
composer config -g repo.packagist应输出空或报错，而非返回 URL - 清完再配代理，否则所有代理设置都是摆设
如何验证代理真正生效
别信“没报错就成功”，要看到日志里明确出现 Proxy CONNECT 才算走通。
- 临时加参数运行：
composer install -n -vvv，搜索日志中是否有Proxy CONNECT - 检查配置是否写入：
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且格式正确 - 手动测试代理连通性：
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json，能返回200 OK才说明代理服务本身可用
企业环境常见坑：NTLM 代理和证书信任
如果公司用 Windows 域环境的 NTLM 代理，Composer 原生不支持，直接配 http-proxy 会返回 407 Proxy Authentication Required。
- 必须引入中转代理工具（如
cntlm或px），让它监听127.0.0.1:3128并处理 NTLM，再让 Composer 连这个本地地址 - TLS 握手失败（
SSL certificate problem）通常是因为公司根证书未被信任，需执行composer config -g cafile /path/to/your-root.pem - Windows + WSL2 用户常因系统时间不同步导致握手失败，运行
sudo hwclock -s同步主机时间
最易被忽略的一点：代理配置后仍慢或失败，问题往往不在 Composer 本身，而在代理进程是否启动、端口是否被防火墙拦截、或代理服务是否支持 CONNECT 隧道——这些必须逐层验证，不能只盯着 composer.json 或配置命令看。
