想让Composer安装Workerman更快?配置Composer镜像加速!
Workerman 本身并不依赖什么特殊网络环境,但当你执行 composer require workerman/workerman 时,如果进度条卡住不动或慢得让人抓狂,十有八九是 Composer 还在直连海外的 packagist.org。换国内镜像源这一步,不是可选项,而是必须跨过去的门槛
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 直接跑,照样起不来——先确认运行环境,再谈安装速度。


































