答案：永久切换阿里云镜像源的正确命令是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，末尾composer类型标识不可省略，否则composer diagnose报错；该命令全局生效、优先级高于项目配置，且兼容composer 2.x/1.10+。
composer install 卡在 downloading 或报 The process timed out，根本不是你网络断了，而是默认连 packagist.org —— 这个源在国内基本靠“祈祷”才能通。换镜像源 + 合理调超时，才是真解法；光拉长 timeout 只是硬扛，治标不治本。
如何用一行命令永久切换阿里云镜像源
执行这条命令即可全局生效（Composer 2.x / 1.10+ 都支持）：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意末尾的 composer 类型标识不能少，否则 composer diagnose 会报 Repo is not configured properly。
- 验证是否成功：运行
composer config -g repo.packagist，输出应为完整 URL +{"type": "composer", ...}结构 - 如果提示
Could not find package，大概率是~/.composer/config.json权限不对，可手动编辑该文件，在repositories下加对应条目 - 别用
composer config -g repositories.packagist.type composer这种分步写法——容易覆盖整个repositories数组，把私有源也干掉 - 公司有私有仓库？建议设为代理而非完全替换：
composer config -g repos.aliyun composer https://mirrors.aliyun.com/composer/，再禁用默认源：composer config -g repos.packagist false
为什么只改 composer.json 里的 repositories 不靠谱
很多人直接在项目 composer.json 里加一段镜像配置，看似简单，实则埋雷：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 镜像地址随代码提交到 Git，协作时可能泄露内部配置，或导致不同环境行为不一致
- repositories 数组顺序敏感：如果没把新源排第一，Composer 仍可能 fallback 到
packagist.org，你根本不知道它偷偷连了国外 - 和全局配置叠加时，容易触发
Package not found错误，排查要翻日志、比配置、查优先级 -
composer config -g写入的是~/.composer/config.json，完全隔离于项目，且优先级高于项目配置，逻辑干净
process-timeout 和 http-basic-timeout 怎么设才有效
process-timeout 控制整个命令生命周期（含依赖解析、下载、解压、脚本执行），默认 300 秒；http-basic-timeout（Composer 2.2+）控制单次 HTTP 请求连接/读取时限，默认 60 秒。两者必须同步调高，只改一个常无效。
- 临时生效（适合 CI 调试）：
composer install --timeout=1800 --http-basic-timeout=300 - 永久生效（推荐）：
composer config -g process-timeout 1800+composer config -g http-basic-timeout 300 - 值设为 0 表示不限时，但极危险：DNS 解析失败或镜像不可用时，
composer会无限 hang 住，CI 流水线卡死几小时都无感知 - 超过 7200 秒（2 小时）会被 Composer 硬编码强制回退到 300 秒，所以别设 24 小时——真要跑那么久，说明链路已出问题，该查代理或镜像连通性
换完镜像还超时？先确认是不是真走通了
很多人执行完 composer config -g 就以为搞定了，结果 composer install 还是卡在 downloading。这时候得验证镜像是否真正生效：
- 运行
composer config -g repos.packagist，输出必须是带"type": "composer"的对象，不是字符串 URL - 手动测镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json，看能否秒回HTTP/2 200 - 如果
curl也超时，问题不在 Composer 配置，而在本地网络：检查系统代理（尤其是 Windows “自动检测设置”）、杀毒软件 HTTPS 扫描、公司防火墙拦截 TLS 握手 - 企业网用户务必配代理：
export HTTPS_PROXY=http://your-proxy:8080（只设HTTP_PROXY没用，Composer 默认全走 HTTPS）
vcs 类型包仍直连 GitHub，此时镜像源完全不起作用；又比如 CI 环境每次都是干净容器，没缓存、DNS 策略严、内存受限，而默认配置根本没考虑这些。解决超时，从来不是改一个参数就能收工的事。
