Hyperf项目安装卡顿的根源在于镜像配置错误、lock文件未更新及autoload未优化。正确配置镜像需执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并重写lock文件；必须用create-project而非require；启动慢主因是autoload加载与OPcache未预热，需执行composer dump-autoload --optimize --classmap-authoritative并预热OPcache。
composer config -g repo.packagist 命令必须带 type 参数
Hyperf 项目安装卡在 Loading composer repositories，大概率不是网络差，而是镜像配置静默失效。命令里漏掉 composer 这个 type 值，Composer 就当没这回事——不报错、不提示、照连 packagist.org。
正确写法只有一条：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。注意三点：
-
repo.packagist是唯一合法键名，写成repos.packagist或Repo.Packagist全无效 - 中间的
composer是强制 type 值，不能省略，也不能换成vcs或空字符串 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出 404 路径）
执行后立刻验证：composer config -g repo.packagist 输出必须是完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。如果为空、null 或还是 https://packagist.org，说明根本没写进去。
换源后必须重写 composer.lock 才真正生效
即使全局镜像配对了，composer install 仍可能卡在 downloading hyperf/cache v3.1.0——因为 composer.lock 里存的是原始 dist.url，Composer 会先尝试这个地址，失败才 fallback，且 fallback 不保证成功。
解决办法只有一条：composer update --lock。它会强制重写 lock 文件中所有包的 dist.url，全部指向镜像源。
特别注意：
- 已有项目的
composer.lock不能跳过这步 - 新项目用
composer create-project时，建议加--repository=https://mirrors.aliyun.com/composer/直连镜像，避免首次拉取元数据就卡住 - 验证是否生效：打开
composer.lock，搜任意一个hyperf/包，看它的dist.url字段是不是https://mirrors.aliyun.com/composer/dists/...
Hyperf 必须用 create-project，不能 require
直接 composer require hyperf/http-server 到已有项目，90% 概率启动报 Class 'Hyperf\Contract\ContainerInterface' not found。这不是镜像问题，而是 Hyperf 启动流程被跳过了。
Hyperf 的 DI 容器、代理类生成、注解扫描全靠 HyperfDevtoolComposerScriptHandler::build 脚本驱动，这个脚本只在 create-project 或 install（非 update）且未加 --no-scripts 时触发。
正确做法：
-
composer create-project hyperf/hyperf-skeleton:3.2.0 my-app --prefer-dist -n（锁死 patch 版，避免dev-main） - 进项目后，别改
composer.json然后composer install——容易漏掉 autoload 配置和版本约束 - 添加第三方包时，优先选协程安全的，比如用
hyperf/redis替代predis/predis，用hyperf/http-client替代guzzlehttp/guzzle
镜像再快，也救不了 autoload.php 加载慢
换了阿里云镜像，composer install 快了，但 php bin/hyperf.php start 启动仍要 600ms+？那卡点根本不在下载，而在 vendor/autoload.php 加载和 classmap 构建。
Hyperf 启动耗时大头是：
-
vendor/autoload.php注册与 PSR-4 扫描：280–650ms（未优化时） - OPcache 初始化与核心类预热：可压到 50ms 内，但需手动
opcache_compile_file() - Swoole Server worker 创建：80–120ms
所以构建阶段必须做三件事：
-
composer dump-autoload --optimize --classmap-authoritative（验证：grepclassMap =vendor/autoload.php 应有非空数组） - Dockerfile 中在
ENTRYPOINT前加 OPcache 预热逻辑 -
composer install --no-dev --no-scripts --prefer-dist剥离调试工具，否则vendor/bin里一堆phpunit会拖慢容器启动
镜像源只管下载快慢，真正影响“秒级就绪”的，是构建时有没有把 autoload 和 opcache 这两关做实。漏掉任意一步，运行时都补不回来。
