必须同时执行composer config -g --unset http-proxy和composer config -g --unset https-proxy，并运行composer clear-cache，否则缓存未清或残留代理/环境变量仍会导致请求失败或静默回退。
composer config -g --unset https-proxy 和 http-proxy 必须同时执行
只删其中一个字段，Composer 仍会用另一个发起请求，导致 HTTPS 请求直连失败或卡在 Loading composer repositories。必须两条命令都运行：
composer config -g --unset http-proxycomposer config -g --unset https-proxy
注意：不加 -g 只影响当前项目，换目录就失效；字段名是 http-proxy 和 https-proxy（带连字符），不是 http_proxy 或 HTTP_PROXY 环境变量。
删完代理后还要清缓存才真正生效
Composer 会缓存仓库元数据（如 packages.json），即使代理已删，旧缓存仍可能指向镜像或错误地址，继续报错。必须紧接着执行：
composer clear-cache
否则你会看到 composer config -g --list 已无 proxy 字段，但 composer install 依然走老路径——缓存没清，配置就“假装生效”了。
检查是否被环境变量或 COMPOSER_REPO_PACKAGIST 干扰
代理删了，但 Composer 还是连不上？可能是这些隐藏配置在起作用：
- 环境变量
HTTP_PROXY、HTTPS_PROXY仍存在（尤其 PowerShell 或终端未重启） -
COMPOSER_REPO_PACKAGIST被设为镜像地址，它优先级高于 config.json - 项目级
composer.json里有"repositories"块，覆盖了全局行为
验证方式：echo $HTTP_PROXY（Linux/macOS）或 echo %HTTP_PROXY%（Windows）；查环境变量源：composer config -g --list | grep -i repo；再看项目根目录下 composer.json 是否含 repositories 字段。
确认是否真回到官方源，不能只看 config 输出
composer config -g repos.packagist 返回 “Key does not exist” 只说明没显式配置镜像，不代表一定走官方源。真正验证要看实际请求地址：
composer require monolog/monolog --no-install -vvv
观察日志中类似 Downloading https://repo.packagist.org/packages.json 的行——出现 repo.packagist.org 才算成功；若仍是 mirrors.aliyun.com，说明项目级配置或环境变量还在接管。
