只删 Composer 配置还不够，因 create-project 等命令会继承 shell 环境变量中的 http_proxy/https_proxy 并由 git/curl 直接使用，须同步清空 Composer 全局配置、shell 环境变量（临时及持久）和 no_proxy，再分层验证 curl 与 config 输出是否均无代理痕迹。
Composer 会忽略系统环境变量，但你仍需主动清空它——否则某些命令（如 composer create-project）可能意外继承并干扰直连逻辑。
为什么只删 Composer 配置还不够
很多人执行了 composer config --global --unset http-proxy 和 composer config --global --unset https-proxy，却仍发现 composer install 走代理。这不是 Composer “没生效”，而是：某些子命令（尤其是调用外部进程的，比如 create-project 中的 git clone 或 curl）会读取 http_proxy、https_proxy 等环境变量，并自行走代理——这和 Composer 自身的网络栈无关，属于底层工具链行为。
常见表现：
-
composer install正常直连，但composer create-project laravel/laravel myapp卡在Cloning into 'myapp'... -
composer diagnose显示 “HTTP proxy: none”，但git或curl仍在用代理
必须同时清理三处代理来源
直连配置不是“设一个开关”，而是确保没有代理路径可被任何环节拾取：
- Composer 全局配置：
composer config --global --unset http-proxy和composer config --global --unset https-proxy - Shell 环境变量（临时）：运行前加前缀，例如
http_proxy= https_proxy= composer install（macOS/Linux）或$env:http_proxy=""; $env:https_proxy=""; composer install（PowerShell） - Shell 环境变量（持久）：检查
~/.bashrc、~/.zshrc或 Windows 的系统属性 → 环境变量界面，删掉http_proxy、https_proxy、no_proxy等条目
注意：no_proxy 不影响 Composer 直连判断，但它若错误包含 packagist.org，会导致本该走代理的请求被绕过——而你现在要的是彻底直连，所以干脆清空更稳妥。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证是否真直连：别信 composer diagnose 单一输出
composer diagnose 只检查 Composer 自己的配置，不检测底层工具链。真正验证方式是分层确认：
- 运行
composer config --global --list | grep -E "(http|https)-proxy"—— 输出应为空 - 运行
env | grep -i proxy（macOS/Linux）或Get-ChildItem Env: | Where-Object Name -like "*proxy*"（PowerShell）—— 应无输出 - 手动模拟 Composer 内部请求：
curl -v https://repo.packagist.org/packages.json，看* Connected to repo.packagist.org是否直接连到 IP，而非跳转到代理地址
如果 curl 仍走代理，说明环境变量或 shell 配置没清干净；如果 curl 直连成功但 composer install 还卡住，问题大概率出在 DNS 或 TLS 证书信任链，和代理无关。
CI/CD 中绕过代理的推荐写法
在 GitHub Actions、GitLab CI 等场景下，不建议修改全局环境变量，而是用最简前缀屏蔽：
- GitHub Actions：
http_proxy: ''和https_proxy: ''写进env:块，作用域精准，不污染 runner - GitLab CI：
variables:下设HTTP_PROXY: ""和HTTPS_PROXY: ""（注意大小写，GitLab 默认全大写） - 避免用
unset命令——CI 容器生命周期短，环境变量默认为空，显式设空更可靠
复杂点在于：有些私有仓库（如 GitLab 私有 Group）依赖公司 NTLM 代理才能访问，而 packagist.org 又必须直连。这种混合网络策略无法靠单一配置解决，必须拆成两套流程——要么用 repo.packagist.org.proxy 细粒度控制（Composer ≥ 2.2），要么用 composer config --global repo.packagist.org.ssl-proxy "" 强制对 packagist 直连，其他源另配。
