composer代理必须同时配置http-proxy和https-proxy，且https-proxy值仍须以http://开头；漏配任一或url未编码特殊字符，将导致https请求直连超时，卡在“loading composer repositories”。
Composer 代理配置不是“设了就能用”，而是必须同时配 http-proxy 和 https-proxy，且 https-proxy 的值仍得写成 http:// 开头——漏掉任一字段，composer install 就会卡在 “Loading composer repositories”，实际是 HTTPS 请求直连失败。
为什么只配 http-proxy 不行？
Packagist、GitHub 等所有主流仓库默认走 HTTPS，而 Composer 的 http-proxy 配置仅对 HTTP 协议生效。HTTPS 请求完全不走这个字段，也不会自动 fallback 或复用它。
-
https-proxy必须单独设置，命令是：composer config --global https-proxy http://127.0.0.1:8080 - 即使你的代理本身监听 HTTPS（如
https://127.0.0.1:443），这里也必须填http://——这是 Composer 的硬性解析规则，填https://会静默失效 - 验证是否生效：运行
composer config --global --list | grep -E "(http|https)-proxy"，必须看到两行输出
http://user:pass@proxy:port 里密码含 @、/、: 怎么办？
Composer 解析代理 URL 时，只认第一个 @ 为用户/密码分隔符，后面的内容全被截断。比如密码是 pa@ss/word，不编码就填，实际解析出的密码只有 pa，剩下 ss/word@proxy:port 被丢弃，报错 Invalid URI supplied 或直接跳过代理。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须对用户名或密码做
rawurlencode()编码：用php -r "echo rawurlencode('pa@ss/word');"得到pa%40ss%2Fword - 完整地址写成：
http://user:pa%40ss%2Fword@127.0.0.1:8080 - 域名里带
@（如dev@corp.com）同样要编码，否则一样被截断
公司用 NTLM 代理（比如 Windows 域控），407 Proxy Authentication Required 怎么破？
Composer 原生不支持 NTLM 认证协议，无论你怎么设 http-proxy，只要代理返回 407，就说明协议层不兼容——这不是配置写错，是根本跑不通。
- 唯一可行解法：在本地起一个中转代理，比如
cntlm或px，让它处理 NTLM 认证，再暴露一个普通 HTTP 代理（如http://127.0.0.1:3128），然后让 Composer 连这个地址 - 另一种路径：找 IT 确认是否有免认证的 bypass 代理（常叫 HTTP 出口代理），直接配那个地址
- 别试
disable-tls或改ssl-verifypeer，这解决不了 407，反而引入中间人风险
代理设好了还是卡住？怎么快速定位链路哪一环断了？
现象都是“没报错、只是卡住”，但真实原因可能是代理进程未运行、端口填错、防火墙拦截，或代理本身没放行 packagist.org。
- 先手动验证代理通不通：
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json。能返回200 OK才算代理层通 - 检查 Composer 是否读到了配置：
composer config --global --list | grep proxy，确认两字段都存在且格式正确（协议小写、无多余空格） - 注意环境变量干扰：系统级
HTTP_PROXY优先级高于 Composer 自身配置，建议统一用一种方式，避免混用
真正容易被忽略的点在于：代理配置本身极简，但 Composer 对 URI 格式、协议头大小写、字段完整性极其敏感；任何一处微小偏差（比如少个 http://、多一个空格、https-proxy 漏设）都会导致静默失败，且日志里几乎不提示具体原因。
