配置成功的标志是 composer config -g --list 显示含协议头的 http-proxy 和 https-proxy 两行URL，且 curl -x 能获取200响应；务必执行 composer clear-cache 并用 -vvv 验证实际请求地址。
运行 composer config -g --list 看是否写入成功
这一步只确认配置“有没有存进去”，不保证能用。必须看到两行输出，且都含合法 URL：
-
http-proxy和https-proxy两个字段必须同时存在 - 值必须是完整 URL，带协议头（
http://），不能是https://或裸 IP+端口 - 若含认证信息（如
user:pass@），其中的@、/、:必须已做rawurlencode编码，否则会被截断
常见失败现象：只看到一行、URL 缺协议头、密码里有 @ 却没编码 → 后续所有 HTTPS 请求都会静默 fallback 到直连。
用 curl -x 手动复现 Composer 的 CONNECT 隧道行为
Composer 访问 Packagist 时，实际走的是 https-proxy 发起的 HTTP CONNECT 隧道。所以验证代理本身是否通，不能只测 curl https://packagist.org，而要模拟隧道建立：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行：
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json - 期望返回 HTTP 200 或 304；若返回 502，说明代理服务自身异常（如上游不通、TLS 终止失败）
- 若卡住或报
curl: (35) SSL connect error，大概率是代理未透传 SNI 或降级了 TLS 协议，和 PHP/curl 版本有关 - Windows 用户注意：PowerShell 中
-x参数需加引号，否则@符号可能被解析为作用域操作符
加 -vvv 看真实请求地址和响应状态
配置和代理链都看似正常，但 composer install 仍卡在 Loading composer repositories？这时必须看底层网络行为：
- 运行：
composer -vvv install，日志中会打印出真实发起的 GET 请求 URL - 重点找类似
GET https://mirrors.aliyun.com/composer/packages.json这样的行 —— 它才是 Composer 实际访问的地址 - 如果 URL 是
https://packagist.org/...，说明镜像配置没生效（可能被项目级repositories覆盖，或没清缓存） - 如果 URL 正确但无后续响应，再回头查
curl -x是否真通；若有 407（Proxy Auth Required），说明代理需要 NTLM 认证，得用cntlm中转
别忽略 composer clear-cache 这个关键动作
改完 https-proxy 或镜像源后，Composer 不会自动刷新本地元数据缓存。旧缓存里存着 packagist.org 的包列表快照，它会继续尝试直连老地址：
- 必须手动执行：
composer clear-cache - 之后再跑
composer -vvv install，才能确保走新配置 + 新隧道 - 如果还失败，可顺手删掉
vendor/和composer.lock（非必需，但能排除本地状态污染） - Windows 下若提示
Could not write to file，检查%APPDATA%\Composer\config.json目录是否存在且当前用户有写权限
composer -vvv 日志里出现你预期的镜像域名，并且 curl -x 能拿到 200 响应。中间任何一环断开，都会表现为“卡住”或“502”，但原因可能在代理进程、TLS 握手、CA 证书、甚至 DNS 解析——得一层层剥开看。 
