composer镜像配置对hyperf秒级就绪无直接帮助，因其仅加速install下载，而真正卡点是autoload加载（280–650ms）、opcache初始化与swoole服务器启动；必须在构建阶段执行composer dump-autoload --optimize --classmap-authoritative、预热opcache并多阶段精简镜像。
composer 镜像配置对 Hyperf 微服务“秒级就绪”没直接帮助——它只加速 composer install 阶段，而 Hyperf 服务真正卡在启动就绪的环节，是 autoloader 加载、OPcache 初始化、协程服务器冷启动这三步。
为什么改 Composer 镜像源后，Hyperf 还是慢启动？
你在 Dockerfile 里加了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，构建确实快了几秒，但容器 docker run 启动时：
• composer 进程早已退出，镜像源配置完全不生效
• Hyperf 启动入口（bin/hyperf.php start）会立即加载 vendor/autoload.php，此时走的是 classmap 还是 PSR-4 动态扫描，取决于构建时是否加了优化参数，跟镜像源无关
• 若未预热 OPcache、未启用 classmap-authoritative，首次请求仍要遍历 vendor 目录，耗时 400ms+
Hyperf 启动卡点在哪？关键不是下载，而是加载
实测典型卡点分布（PHP 8.2 + Swoole 5.1）：
• vendor/autoload.php 加载与注册：280–650ms（未优化 classmap 时）
• opcache_compile_file() 预热核心类：可压到 50ms 内（需手动 preload）
• Swoole Server 初始化（worker 创建、端口绑定）：80–120ms
• hyperf/database 连接池首次建连（若未预热）：额外 150ms+
- 所有这些都发生在
php bin/hyperf.php start执行后、第一个请求到达前 - 镜像源再快，也救不了 autoload.php 里那几万行
require和class_exists判断
真正让 Hyperf 秒级就绪的三件事
必须在构建阶段完成，不能靠运行时补救：
• 显式执行 composer dump-autoload --optimize --classmap-authoritative —— 不是 install 自带的，必须单独跑；验证方式：grep "classMap =" vendor/autoload.php 应有非空数组
• 在 ENTRYPOINT 前预热 OPcache：php -d opcache.enable=1 -d opcache.preload=/app/preload.php -f bin/hyperf.php start，其中 preload.php 包含 opcache_compile_file('vendor/hyperf/framework/src/Application.php') 等高频类
• 多阶段构建剥离 dev 依赖和调试工具：RUN composer install --no-dev --no-scripts --prefer-dist，否则 vendor/bin 里的 phpunit、php-cs-fixer 全打进镜像，体积涨 30%，拉取和解压都拖慢启动
Hyperf 特定陷阱：别在启动时动态 require
常见错误写法：
• 在 config/autoload/processes.php 里用 include 加载未预编译的自定义进程脚本
• 在 Command 类里 require_once __DIR__ . '/Helper.php'，且该文件不在 classmap 中
• 使用 Hyperf\Contract\ConfigInterface 读远程配置中心（如 Apollo），首次调用触发 HTTP 请求阻塞主线程
- 所有这些都会让第一个请求延迟翻倍，且无法被 OPcache 预热覆盖
- 正确做法：静态配置打包容器，动态逻辑改用异步 task worker 处理
- Hyperf 的
scan模式（注解扫描）默认开启，若业务代码大量用@Inject或@Value，务必确认scan配置已关闭或白名单收敛，否则启动时扫描整个app/
