composer install默认不读http_proxy/https_proxy环境变量，只认自身配置的http-proxy和https-proxy两个键，且必须同时配置、协议匹配，否则https请求（如packagist.org）会静默失败。
composer install 为什么完全不读 HTTP_PROXY 环境变量
因为 composer install 默认跳过所有系统级代理环境变量，包括 HTTP_PROXY 和 HTTPS_PROXY。这不是 bug，是 Composer 的硬编码行为——它只认自己配置体系里的 http-proxy 和 https-proxy 两个键。
常见错误现象：Resolving dependencies 卡住、cURL error 35、Failed to decode response，基本都源于只配了其中一个协议，或代理地址本身不支持 CONNECT 隧道。
-
http-proxy只影响纯 HTTP 请求（极少用），对https://packagist.org这类 HTTPS 源完全无效 -
https-proxy必须指向支持 CONNECT 的代理服务（如 Clash、Squid 4.0+），否则连接会被静默拒绝，无报错提示 - 必须同时配置两个键，且协议要匹配：比如
https-proxy不能填http://127.0.0.1:7890，得是https://或http://（取决于代理自身监听方式）
全局 proxy 配置被项目级 repositories 覆盖的真相
只要项目根目录 composer.json 中存在 "repositories" 字段（哪怕只是空数组 []），Composer 就会彻底忽略全局 proxy 配置（即 ~/.composer/config.json 里的 http-proxy 和 https-proxy）。
这不是优先级“覆盖”，而是作用域切换：项目级配置启用后，全局配置直接不加载。验证方式是运行 composer config -g http-proxy（有输出）再执行 composer install（却没走代理），就说明被屏蔽了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想让 proxy 在项目中生效？只能在项目级
composer.json里加"config": {"http-proxy": "...", "https-proxy": "..."} - 但更推荐的做法是：删掉
"repositories"字段，改用国内镜像源（如阿里云），一劳永逸避开代理问题 - 腾讯云等内网 VPC 环境下，根本不需要代理——连通性测试失败时，先确认是否真需要走代理，而非盲目配
proxy 和镜像源混用时的实际行为
proxy 和镜像源不是互斥选项，但混用时容易误判失败原因。例如你配了阿里云镜像 + 全局 https-proxy，结果仍失败，大概率是 proxy 本身无法访问该镜像域名（如 mirrors.aliyun.com 被代理策略拦截）。
Composer 的请求链是：先走 proxy（如果配置了且未被禁用），再发往镜像 URL。所以镜像地址必须能被 proxy 正确转发，而不是“镜像快就一定没问题”。
- 验证 proxy 是否真生效：在 proxy 服务端看日志，或临时把
https-proxy指向一个本地 nc 监听端口（nc -lvp 8888），再跑composer install，看是否有连接进来 - 镜像 URL 域名解析由 proxy 所在机器完成，不是本地机器——如果你的 proxy 运行在跳板机上，要确保那台机器能解析并访问镜像域名
- 不要在 Docker 容器里既配 proxy 又配镜像：容器网络模型下，proxy 往往多一层 NAT，故障点翻倍；优先选镜像，proxy 仅作备用路径
为什么删 vendor 和 composer.lock 是 proxy 配置生效的前提
因为 composer.lock 文件里固化了每个包的下载 URL 和哈希，这些 URL 来自上次解析时实际命中的源。如果你之前没配 proxy 就装过一次，lock 文件里记录的就是直连 repo.packagist.org 的地址，后续即使配了 proxy，Composer 也会照着 lock 里写的 URL 去请求——而那个地址很可能绕过 proxy。
换句话说，proxy 配置只影响“依赖解析阶段”的元数据请求（packages.json），不影响“安装阶段”的包文件下载（zip/tar.gz），除非你强制重解析。
- 必须删除
vendor/和composer.lock后再执行composer install，才能让新 proxy 配置参与完整流程 - 也可以用
composer update --lock强制刷新 lock 文件，但效果等同于删 lock 后重装 - CI/CD 流水线中，建议每次构建前清空
vendor并指定--no-cache，避免缓存污染导致 proxy 行为不一致
repositories 会静默废掉全局 proxy，而旧 composer.lock 会让 proxy 根本没机会介入下载环节。
