换镜像源不能直接快速搭建，必须三要素齐全（repo.packagist键名、composer type值、url末尾斜杠），并清缓存、执行composer update --lock重写composer.lock，再配合--no-dev --prefer-dist --optimize-autoloader参数才有效。
换镜像源本身不能“快速搭建”，它只解决下载卡顿；真正卡住你的，往往是 composer.lock 里残留的境外 URL、全局配置写错、或没清缓存——这些不处理，换再快的镜像也白搭。
composer config -g repo.packagist 命令必须三要素齐全
这条命令不是“设个地址”那么简单，漏掉任意一项就会静默失效，且不报错：
-
repo.packagist是唯一合法键名，写成repos.packagist或packagist.org全无效 -
composer是强制 type 值，不能省略，也不能写成vcs或空字符串 - 镜像 URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出 404 路径）
正确执行：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist 输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。若为空、null 或提示 No repositories configured，说明没写进去。
换了镜像还是卡在 downloading hyperf/cache？重写 composer.lock 是关键
即使全局镜像已生效，composer.lock 里仍存着原始 packagist.org 的 dist.url，Composer 会优先尝试这个地址，失败后才 fallback——而 fallback 不保证成功，尤其在 CI 环境下常直接超时。
必须执行：composer update --lock 强制重写 lock 文件中的所有下载链接，让它们全部指向镜像源。
如果项目已有 vendor/ 和 composer.lock，别跳过这步；新项目用 create-project 时，建议加 --repository 参数直连镜像更保险：
composer create-project hyperf/hyperf-skeleton my-app --repository=https://mirrors.aliyun.com/composer/
验证是否真走镜像：打开 composer.lock，搜索任意一个 hyperf/xxx 包，看其 dist.url 字段是否为 https://mirrors.aliyun.com/composer/dists/... 类路径。
Hyperf 安装时漏掉这几个参数，照样慢得不行
Hyperf 包多、体积大，光换镜像不够，还得配合参数控制安装行为：
-
--no-dev：跳过require-dev中的 phpunit、php-cs-fixer 等工具，减少 vendor 体积和 autoload 扫描量 -
--prefer-dist：优先下载 ZIP 包而非 Git 克隆，节省解压前的网络耗时 -
--optimize-autoloader：生成 classmap，避免运行时 PSR-4 动态查找，对启动速度影响显著
推荐组合：composer install --no-dev --prefer-dist --optimize-autoloader
注意：composer create-project 默认不带这些参数，必须显式加上；--no-scripts 也要慎用——Hyperf 骨架依赖 post-install-cmd 生成代理类和注解扫描器，跳过会导致启动时报 Class not found。
Docker 构建时镜像源配置完全无效？这是设计使然
在 Dockerfile 里执行 composer config -g repo.packagist ... 只影响构建阶段的 composer install，但容器启动后，PHP 进程根本不读这个配置——它只关心 vendor/autoload.php 怎么加载、OPcache 是否预热、Swoole 是否就绪。
真正影响 Hyperf 启动速度的是构建阶段是否做了三件事：
- 执行
composer dump-autoload --optimize --classmap-authoritative（不是install自带的） - 在
ENTRYPOINT前预热 OPcache，比如用opcache_compile_file()加载核心类 - 用多阶段构建剥离
--no-dev后的调试工具，否则 vendor 体积膨胀 30%，拉取+解压都拖慢启动
镜像源只是第一步，后面这几步才是让 Hyperf “秒级就绪”的真实门槛，容易被忽略，但无法绕过。
