composer 必须同时配置 http-proxy 和 https-proxy 两个字段，缺一不可；因所有仓库均走 https，仅配 http-proxy 会导致 https 请求静默直连超时或卡在“loading composer repositories”。
Composer 不会读 HTTP_PROXY 环境变量，只认自己配置的 http-proxy 和 https-proxy 两个字段，缺一不可——否则所有 HTTPS 请求（包括访问 Packagist）都会静默失败。
为什么只配 http-proxy 还是卡在 “Loading composer repositories”
因为 Packagist、GitHub、镜像源全走 HTTPS，而 http-proxy 只处理纯 HTTP 请求；HTTPS 必须靠 https-proxy 建立 CONNECT 隧道。漏掉它，Composer 就 fallback 到直连，结果是超时、cURL error 35 或无报错卡住。
-
https-proxy的值必须是http://开头（哪怕代理本身监听 HTTPS 端口），填https://127.0.0.1:8080或不写协议头都会静默失效 - 认证信息里的特殊字符（如
@、/、:）必须 URL 编码，例如密码pa@ss/word要写成pa%40ss%2Fword - Windows 下若提示
Could not write to file，检查%APPDATA%\Composer\config.json目录是否可写，或用管理员权限运行命令
腾讯云/CVM 上该配代理还是换镜像
腾讯云服务器默认在公网或 VPC 内，多数情况根本不需要代理——DNS 解析慢、TLS 握手卡在海外节点才是真因。直接切腾讯云官方镜像比配代理更快更稳。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行：
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/（注意末尾/不能少） - 立刻清缓存：
composer clear-cache - 验证：
composer config -g repo.packagist应输出完整 JSON，且url字段含mirrors.cloud.tencent.com - 若项目根目录
composer.json里有repositories字段，它会覆盖全局配置，得先删掉或注释掉
公司 NTLM 代理或国产“加速器”导致 SSL handshake failed 怎么办
这类代理通常做 MITM，动态签发证书，但 PHP 的 OpenSSL 默认不信任它的根证书——不是网络不通，是 TLS 握手阶段就被拒绝了。
- 先临时绕过验证：
HTTP_PROXY= HTTPS_PROXY= composer install，如果成功，基本锁定是代理证书问题 - NTLM 代理（如 Windows 域环境）Composer 原生不支持，必须用
cntlm或px做中转，让它们监听127.0.0.1:3128并处理认证，再让 Composer 连这个本地地址 - 导出代理的根证书，用
openssl.cafile指向它（改php.ini或在composer.json的config段加"cafile": "/path/to/cert.pem"） - 别信
composer diagnose，它只测packagist.org，和你配的镜像无关；真实验证只看curl -I https://mirrors.cloud.tencent.com/composer/packages.json是否返回200和application/json
最常被忽略的一点：代理配置和镜像配置是两套独立机制，混用时容易互相干扰；比如镜像 URL 被代理重写成内部地址，Composer 就会把元数据缓存到错误路径，删错缓存目录也白忙活。
