Composer代理必须同时配置http-proxy和https-proxy，且均以http://开头；漏配任一或特殊字符未URL编码将导致HTTPS请求直连超时，卡在“Loading composer repositories”。
Composer的http-proxy和https-proxy必须同时配
只设http-proxy，composer install照样卡在“Loading composer repositories”，因为 packagist.org 全量走 HTTPS，而 Composer 对协议是严格分流的：http-proxy只管 HTTP 请求，https-proxy才负责建立 CONNECT 隧道处理 HTTPS 流量。漏掉任意一个，对应协议的请求就会直连——多数情况下直接超时或返回 cURL error 7。
关键点在于：https-proxy的值必须是http://开头（不是https://），哪怕你的代理服务本身监听的是 TLS 端口。这是 Composer 的硬性约定，填错就静默失效。
- 正确写法：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890 - 带认证时，密码含
@或:必须先rawurlencode()，例如pa@ss:word→pa%40ss%3Aword - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且格式合法
国际镜像源 ≠ HTTP 缓存代理，别混用
很多人以为配了https://mirrors.aliyun.com/composer/就是“用了代理”，其实这是完全不同的机制：镜像源是独立同步的站点，Composer 直连它，不经过你本地的http-proxy；而代理是网络层中转，所有流量（包括元数据和包文件）都流经你本机端口。
这两者不可共存。一旦你设了repo.packagist.org的 URL（比如切到阿里云镜像），Composer 就会忽略http-proxy和https-proxy配置——因为请求目标变了，不再发往packagist.org，自然不走代理逻辑。
- 想走代理 + 连国际源：只配
http-proxy/https-proxy，不要动repo.packagist.org的 URL - 想连国内镜像：直接改
repo.packagist.org，并清缓存：composer clear-cache - 二者混用（比如既设代理又切镜像）会导致行为不确定，常见现象是部分请求走镜像、部分被代理劫持，最终 404 或 fallback 到官方源
密码含特殊字符时 rawurlencode 是必须步骤
Composer 解析代理 URL 时不做自动编码，遇到未编码的@、:、/会截断 URI，导致认证失败或连接拒绝。这不是可选项，是必填项。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
错误示例：http://user:pa@ss:word@127.0.0.1:7890 —— Composer 会把第一个@当作用户名/密码分隔符，后面全当主机名，结果连不到代理服务。
- 生成编码后密码：
php -r "echo rawurlencode('pa@ss:word');"→ 输出pa%40ss%3Aword - 拼完整地址：
http://user:pa%40ss%3Aword@127.0.0.1:7890 - Windows 用户注意：
%在 CMD 中有特殊含义，建议用 PowerShell 或双写%%避免被提前解析
NTLM 代理不能靠 Composer 原生支持解决
公司内网常见的 Windows 域环境 NTLM 代理，Composer 原生不支持。设了http-proxy也会直接返回 407 Proxy Authentication Required，不是配置问题，是协议不兼容。
唯一可行方案是引入本地中转代理工具，比如cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM 认证，再让 Composer 连这个本地地址。
- 验证中转是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果 curl 也报 407，说明中转层没配好 - Composer 配置仍按常规来：
composer config -g http-proxy http://127.0.0.1:3128和https-proxy同理 - 别指望系统级
HTTP_PROXY环境变量能绕过——Composer 明确忽略它，只认自己的字段
真正容易被忽略的是：代理配置生效后，Composer 不会主动告诉你它连的是哪个地址。要确认是否真走代理，得开-vvv看日志里的GET行，或者抓包查实际 TCP 连接目标。很多“配好了但没生效”的问题，其实只是没验证这一步。
