想让Composer安装Workerman更快？配置Composer镜像加速！

Workerman 本身并不依赖什么特殊网络环境，但当你执行 composer require workerman/workerman 时，如果进度条卡住不动或慢得让人抓狂，十有八九是 Composer 还在直连海外的 packagist.org。换国内镜像源这一步，不是可选项，而是必须跨过去的门槛——最直接、最立竿见影。

composer config -g repo.packagist 命令必须写对三个硬性条件

很多人执行完命令发现速度没变，不是镜像本身不行，而是命令根本没生效。这里有几个细节，错一个就白忙活：

• repo.packagist 不能写成 repos.packagist（多一个 s）或 packagist（少了 repo. 前缀）。Composer 遇到这种拼写错误，直接忽略，连个报错都不给。
• 中间的 composer 是 type 值，绝对不能省。漏掉它，Composer 2.2+ 会静默 fallback 回官方源，你完全察觉不到。
• URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，而 https://mirrors.aliyun.com/composer ❌（少斜杠会导致 packages.json 返回 404，然后自动退回去）。

验证是否生效很简单：运行 composer config -g repo.packagist，输出的必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果输出是空、null 或只显示一个字符串 URL，都说明没写进去。

项目级配置比全局更可靠，尤其搭配 Workerman 使用时

Workerman 经常跑在 CLI 场景下（比如 php start.php start -d），而很多部署环境（宝塔、Jenkins、Docker）里执行 Composer 的用户，和你本地终端的用户不是同一个。全局配置在这种场景下可能完全不生效：

• 进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。
• 这条命令会安全地往 composer.json 的 repositories 字段里加一条 "packagist" 条目，不会清空你已有的私有源。
• 如果项目已有 "repositories": { "my-private": { "type": "vcs", ... } }，手动编辑时务必同时在 composer.json 根节点加 "packagist.org": false，否则私有源和镜像共存时可能冲突。

这样配置后，所有协作者、CI 流水线、宝塔「一键部署」都会走同一镜像，生成的 composer.lock hash 也一致，省心不少。

换源后 composer require workerman/workerman 还卡在 Resolving dependencies？那和镜像无关

镜像只加速元数据请求（如 packages.json）和 tarball 下载，不影响依赖解析逻辑。如果卡在 Resolving dependencies，大概率是项目已有复杂约束（比如锁定了 PHP 版本、其他包的旧版本），跟网络无关。可以加 -vvv 看具体卡在哪条规则。

Workerman 安装成功但运行报 undefined function pcntl_fork()，那是 PHP CLI 没启用 pcntl 扩展，不是 Composer 的问题。首次用新镜像执行 composer install 或 require 若报 hash 不匹配，删掉 vendor/ 和 composer.lock 重来最稳妥。

真正容易被忽略的是：Workerman 依赖系统扩展和 CLI 环境。镜像再快，pcntl 关着、PHP 版本不对、或者用 Windows CMD 直接跑，照样起不来——先确认运行环境，再谈安装速度。