结论：国内企业或校园网环境下composer install卡住主因是ntlm代理未被支持，需本地起cntlm等中转代理；必须同时配置全局http-proxy与https-proxy为http://127.0.0.1:3128，并设置镜像源，二者串联生效。
直接说结论：国内企业或校园网环境下，composer install 卡在 Resolving dependencies 或长时间停在 Downloading，大概率不是镜像没配好，而是根本没走代理——尤其当你公司用 NTLM 认证代理时，Composer 原生不支持，必须本地起中转代理。
为什么配了镜像还卡在 HTTPS 请求上？
很多人以为“配了阿里云镜像就万事大吉”，但实际链路是：composer install → 发起 HTTPS 请求 → 系统网络策略强制所有 HTTPS 流量过公司代理 → 代理返回 407 Proxy Authentication Required → Composer 静默卡住或超时。
Composer 不识别 NTLM、Kerberos 等企业级认证协议，http-proxy 和 https-proxy 配置项只接受基础 HTTP 代理地址，不处理认证逻辑。
- 只配
http-proxy没用：HTTPS 请求不会走它 - 只配
https-proxy且填https://开头会静默失效（必须是http://127.0.0.1:3128这种格式） - 镜像源 URL（如
https://mirrors.aliyun.com/composer/）仍是 HTTPS，仍需过代理
怎么让 Composer 正确走本地中转代理？
核心思路：用 cntlm 或 px 在本机监听 127.0.0.1:3128，把 NTLM 认证封装掉，再让 Composer 连这个地址。
以 cntlm 为例（Windows/macOS/Linux 均可用）：
- 安装并配置
cntlm，填入你的域账号、密码、域名和公司代理地址（如proxy.corp.com:8080） - 启动
cntlm，确认它监听127.0.0.1:3128 - 执行两条命令（缺一不可）：
composer config -g http-proxy http://127.0.0.1:3128composer config -g https-proxy http://127.0.0.1:3128 - 验证：
composer config -g --list | grep -E "(http|https)-proxy"，输出应含两行且协议为http://
代理 + 镜像混用时最容易踩的坑
常见错误是以为“代理和镜像互斥”，其实它们是串联关系：Composer → 本地代理（127.0.0.1:3128）→ 公司代理 → 镜像服务器。漏掉任一环都会失败。
-
repo.packagist配置必须完整：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾斜杠、composertype、无多余 s） - 执行
composer clear-cache，否则旧缓存里可能还存着 packagist.org 的元数据，会绕过镜像直连海外 - 检查当前用户：宝塔、CI 或定时任务常以
www用户运行，但你用root配的 proxy，得切用户重配：sudo -u www composer config -g https-proxy http://127.0.0.1:3128 - 别信
composer install -vvv日志里“Using repository”那行——它只表示用了哪个仓库定义，不等于实际请求发到了哪；真要看流量走向，得抓包或看cntlm日志
最常被忽略的一点：代理配置和镜像配置必须同时生效，且都作用于全局（-g），项目级 composer.json 里的 repositories 会覆盖全局镜像，但不会绕过代理——除非你手动删掉 http-proxy 配置。
