必须换镜像，因 packagist.org 对国内 ip 限频导致访问慢、超时；执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 即可全局切换。
Composer 默认源访问慢、超时、被限频，不是你的网络问题，是 packagist.org 本身对国内 IP 的连接策略导致的。换镜像不是“锦上添花”，而是必须做的基础配置。
如何快速切换到阿里云 Composer 镜像
阿里云镜像（https://mirrors.aliyun.com/composer/）稳定、同步及时、无需认证，适合绝大多数项目。执行一条命令即可全局生效：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意：config -g 修改的是全局配置（~/.composer/config.json），不影响已有项目的本地配置；如果项目里已手动设过 repositories，优先级更高，需先清理或覆盖。
- 验证是否生效：运行
composer config -g repo.packagist，输出应为该镜像地址 - 若提示
Command "config" is not defined，说明 Composer 版本过低（composer self-update - 某些 CI 环境（如 GitHub Actions）默认不读全局配置，需在
composer install前显式指定：COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install
为什么不能只改 composer.json 里的 repositories
在项目根目录的 composer.json 中写死镜像，看似可控，实则带来三个隐性成本：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 每个新项目都要重复复制粘贴，容易漏或写错（比如少个
/或协议写成http） - 团队协作时，有人忘了加，
composer update就悄悄走原站，失败后才报错，排查耗时 - 依赖包自身声明的
repositories（如私有包）会与项目级配置合并，可能触发意外交互，尤其当多个源定义同名包时
全局配置 + 项目级覆盖（composer config repo.packagist，不带 -g）才是合理分层：统一底座，按需微调。
composer install 仍卡在 loading package information？检查这三处
换镜像后仍卡住，大概率不是镜像问题，而是本地环境干扰：
- 代理残留：确认没启用系统级 HTTP/HTTPS 代理（
env | grep -i proxy），Composer 不自动绕过代理，即使镜像在国内也会被转发出去 - DNS 污染：尝试
ping mirrors.aliyun.com，若解析到异常 IP，改用114.114.114.114或223.5.5.5刷新 DNS - SSL 校验失败：极少数企业网络拦截 HTTPS，临时禁用校验（仅调试用）：
composer config -g secure-http false，但务必在完成后恢复
镜像只是加速手段，真正的瓶颈常藏在锁文件版本陈旧、PHP 扩展缺失（如 openssl、zip）、或 vendor 权限混乱里。别只盯着源地址，先跑通 composer diagnose。
