Composer 代理设置：弃用 REQUEST_FULLURI 标志

Composer 旧的 HTTP_PROXY_REQUEST_FULLURI 及相关 FULLURI 变通做法在文档化的实现中已不再需要，也不再使用。被忽略的标志无法修复正在运行的客户端的路由。

在 POSIX shell 中使用命令行 Composer 时，先在该 shell 中导出受支持的代理变量，再调用 Composer：

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

建议使用小写名称。当代理本身使用普通 HTTP 时，两个值都可以用 http:// 开头；HTTPS 目标并不要求到代理的连接也是 HTTPS。请把示例 endpoint 换成已批准的服务。对于允许使用公共中间人的公共软件包下载，可从 HTTP 代理列表中选择一个 HTTP 候选。

IDE 或构建代理需要在自己的进程环境中拿到这些值。事后再修改持久设置，不会更新已在运行的进程。

当 Composer 在 CLI 之外运行时

对于非 CLI 上下文中的 HTTP 请求，Composer 不使用 http_proxy 或 HTTP_PROXY。它记录的是 CGI_HTTP_PROXY，从而避免把请求头误当作可信的代理配置。不要把 shell 的解决方案复制进 Web 应用，也不要从不可信的请求中获取代理设置。

读懂失败的操作

无法解析的代理名称、被拒绝的连接、407 质询和证书失败指向不同的阶段。请使用第一条有意义的错误，而不是套用旧的 IPv6 或证书校验变通做法。

如果 Composer 的 HTTP 下载正常，但某个基于 Git 的依赖失败，请检查独立的 Git 进程、它的路由及其账号。那是与成功的 Composer 下载不同的消费者。