镜像源和代理不能共存，设了镜像则代理自动失效；必须清空镜像才能启用代理，且https-proxy值必须以http://开头、同时配置http-proxy与https-proxy，并对特殊字符URL编码。
镜像源和代理不能混着配——设了镜像，代理就自动失效；想用代理，就得关掉镜像。这不是 bug，是 Composer 的设计逻辑。
为什么配了镜像还卡在 Loading composer repositories
现象：执行 composer install 时卡住不动，日志停在 “Loading composer repositories”，无报错、不超时、也不下载。
- 大概率是你同时写了镜像配置（如
repo.packagist）又写了http-proxy——Composer 优先走镜像直连，代理字段被忽略 - 验证方法：运行
composer config -g repo.packagist，如果输出非空 JSON（比如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），说明镜像已生效，代理此时完全不参与 - 真要走代理，必须先清掉镜像：
composer config -g --unset repo.packagist
https-proxy 必须写成 http:// 开头
填 https://127.0.0.1:8080 或漏协议头（如 127.0.0.1:8080）会导致静默失败：HTTPS 请求 fallback 到直连，结果就是超时或 502。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确写法永远是
http://127.0.0.1:8080（哪怕代理本身监听 HTTPS 端口） - 带认证时，用户名/密码含
@、/、:必须 URL 编码，例如密码pa@ss/word→pa%40ss%2Fword，可用php -r "echo rawurlencode('pa@ss/word');"生成 - 必须同时设两个字段：
http-proxy和https-proxy，缺一不可；只设前者，HTTPS 流量仍走直连
代理环境下 TLS 握手失败的典型表现
错误信息常是 cURL error 28 或静默超时，不是 timeout 太小，而是证书不被信任。
- 公司代理、Fiddler、Charles 等常用自签名 CA，Composer 默认不认，需手动指定根证书：
composer config -g cafile /path/to/your-root.pem - 同步调高连接容忍度：
composer config -g http.connect_timeout 60和composer config -g http.timeout 600 - Windows + WSL2 时间不同步也会导致 TLS 握手失败，运行
sudo hwclock -s同步主机时间 - 临时验证是否真走代理：加
-n -vvv运行composer install，日志里出现Proxy CONNECT才算成功
企业内网该选镜像还是代理
如果公司已有阿里云、腾讯云或私有 Artifactory 镜像，别配代理——直接切源更稳。
- 镜像不依赖代理进程存活，无 TLS 证书问题，也避免认证类型不匹配（比如 NTLM）
- 全局切阿里镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 私有镜像示例：
composer config -g repo.packagist composer http://internal-mirror.yourcompany.com/composer/ - NTLM 代理无法原生支持，必须前置
cntlm或px做中转，再让 Composer 连127.0.0.1:3128
最容易被忽略的点：镜像和代理是互斥开关，不是叠加选项；而 https-proxy 的协议头必须是 http://，这个硬约束很多人反复踩坑。
