必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；否则Composer静默直连，卡在“Loading composer repositories”。
代理配置写进去了不等于生效，必须同时看到 http-proxy 和 https-proxy 两行输出，且 https-proxy 的值必须以 http:// 开头——否则 Composer 会静默直连，卡在 Loading composer repositories。
运行 composer config -g --list 看是否真写入
Composer 不报错 ≠ 配置成功。它对字段名、协议、格式极其敏感，写错就静默忽略。
-
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890必须都执行，缺一不可 - 检查输出：运行
composer config -g --list | grep -E "(http|https)-proxy"，应明确看到两行，且https-proxy值不是https://或无协议形式 - 若只看到
http-proxy，或https-proxy值是https://127.0.0.1:8080，说明配置被丢弃，不会生效
看 composer install -vvv 日志里有没有 Proxy CONNECT
命令行输出才是最终判决依据。配置再“正确”，日志里没出现代理行为，就是没走通。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加
-vvv运行任意命令（如composer install -vvv），开头几行会打印请求详情 - 关键线索是类似
Downloading https://mirrors.aliyun.com/composer/packages.json via proxy http://127.0.0.1:7890或Proxy CONNECT to packagist.org:443 - 如果只有
Downloading ...没提 proxy，或出现cURL error 28/502 Bad Gateway，基本可断定代理未触发
用 curl -x 单独验证代理连通性
Composer 依赖底层 curl 或 PHP 流，但它的配置不等于系统级代理可用。绕过 Composer 直接测链路更可靠。
- 执行
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json，应返回HTTP/2 200或至少HTTP/1.1 200 - 若返回
407 Proxy Authentication Required，说明代理需要 NTLM 认证——Composer 原生不支持，必须用cntlm或px中转 - 若返回
Connection refused，确认代理进程正在运行，且监听地址与端口和配置一致
防镜像源和代理混配导致静默失效
镜像（repo.packagist）和代理（http-proxy/https-proxy）互斥。二者同时存在时，Composer 优先用镜像，代理字段被完全忽略。
- 运行
composer config -g repo.packagist，如果输出非空（如{"type":"composer","url":"https://..."}），说明镜像已启用，代理此时无效 - 想用代理，必须先清掉镜像：
composer config -g --unset repo.packagist - 企业内网即使用了镜像，若强制所有 HTTPS 流量过代理网关，仍需配
https-proxy，否则 TLS 握手阶段就会失败
真正难的不是写命令，而是确认 https-proxy 的协议头是不是 http://、curl -x 能否通、以及有没有被项目级 repositories 或全局镜像意外覆盖——这些地方都不报错，但会让配置彻底失效。
