代理不是Composer加速首选，多数国内用户应优先用镜像源；混配镜像与代理易致卡死，proxy和ssl-proxy必须成对配置且协议头正确，漏配会导致部分请求直连、行为异常。
代理配置不是 Composer 加速的首选方案，它只在特定网络受限场景下有效；多数国内用户应优先用镜像源，否则容易因协议、证书或超时问题卡死在 SSL handshake 或 404 上。
proxy 和 ssl-proxy 必须成对配置
Composer 对 https://packagist.org 的请求会走两个通道：普通 HTTP 请求（如 packages.json）和 HTTPS 下载（如 dist ZIP）。漏配任一，就会部分请求走代理、部分直连，导致行为不一致甚至中断。
-
composer config -g repo.packagist.org.proxy http://127.0.0.1:7890控制 HTTP 流量 -
composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890控制 HTTPS 流量（注意不是https://开头） - 若代理支持 SOCKS5（如 Clash TUN 模式），可改用
socks5://127.0.0.1:7891，但要求 Composer ≥ 2.2 - 验证是否生效：运行
composer config -g repo.packagist.org.proxy和composer config -g repo.packagist.org.ssl-proxy，两者都必须输出非空值
常见失败现象：没报错，但根本没走代理
这是最坑的情况——命令执行成功，composer install 却仍在连接 https://packagist.org，日志里看不到任何代理相关提示。本质是 Composer 在底层调用 file_get_contents() 时静默 fallback，不会抛异常。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 典型错误日志：
file_get_contents(): SSL operation failed→ 代理未正确透传 TLS，或本地 CA 不被信任；换http://代理可绕过 -
Connection refused或No route to host→ 代理进程未运行、端口填错、或防火墙拦截；用curl -x http://127.0.0.1:7890 https://packagist.org/packages.json手动验证 -
create-project仍慢 → 它第一步就访问packages.json，同样依赖ssl-proxy，漏配就会退回到官方源
Docker 构建中代理几乎不可靠
容器内没有宿主机的代理环境变量，也没有系统级代理配置继承机制。即使你在宿主机配了 proxy，RUN 阶段里 composer install 依然大概率直连官方源。
- BuildKit 的
--mount=type=cache和镜像源才是 Docker 内稳定加速的核心 - 若必须用代理（如企业内网强制走网关），应在每个 RUN 前显式注入：
RUN http_proxy=http://... https_proxy=http://... composer install - Alpine 镜像需额外补证书：
RUN apk add --no-cache ca-certificates，否则 SSL 校验直接失败 - CI 环境（如 GitHub Actions）中，代理配置极易受 runner 网络策略限制，不如直接用阿里云/华为云镜像
真正要提速，先确认你是不是非得用代理——绝大多数国内用户的问题，根源是没配对 repo.packagist 镜像，或者配错了末尾斜杠、type 值、键名复数形式。这些错误全无提示，但会让所有优化归零。
