BootProcess监听器在Hyperf中于容器构建完成、HTTP/GRPC服务器未listen时执行，早于onStart事件；它需实现BootProcessInterface并注册到processes.php，用于安全预热缓存且不可抛异常。
BootProcess监听器在Hyperf中何时执行
Hyperf的BootProcess监听器在容器构建完成、服务尚未启动（即HTTP/GRPC服务器未listen）时运行，早于onStart事件，但晚于配置加载和依赖注入准备。这是预热缓存最稳妥的时机——既可安全使用Container获取服务（如RedisFactory、CacheManager），又不会因服务已对外提供请求而引发并发读写冲突。
如何注册一个可靠的缓存预热BootProcess
必须确保类实现Hyperf\Contract\BootProcessInterface，并正确配置到config/autoload/processes.php中；否则监听器不会被识别。常见错误是忘记在processes.php里注册，或误用Process注解（那是用于长进程，不是BootProcess）。
- 新建类
App\Process\CacheWarmupProcess，实现boot()方法 - 在
config/autoload/processes.php中追加：['App\Process\CacheWarmupProcess' => []]
-
boot()内优先检查缓存是否启用（如$this->container->has(CacheManager::class)），避免在测试环境或禁用缓存时抛异常 - 使用
$this->container->get(RedisFactory::class)->get('default')获取Redis连接，而非直接new实例——保证连接池与主服务一致
预热时读取哪些缓存键才真正有效
盲目GET所有业务键会拖慢启动，且多数键在冷启动时根本不会立刻被访问。应只预热「高频+高延迟生成」的缓存项，比如首页聚合数据、权限菜单树、全局配置快照。这些键通常有固定命名前缀（如cache:home:summary）或由特定服务生成（如PermissionService::buildMenuTree()）。
- 避免预热带用户ID、时间戳等动态参数的键（如
user:123:profile），这类键无法泛化预热 - 若使用Tag机制（如
CacheManager::tag('menu')->remember(...)），可通过Redis的SCAN命令匹配menu:*前缀批量存在性检测，但不建议实际GET全部——只触发关键几条即可 - 对MySQL查询结果缓存，预热前先确认对应SQL已加索引，否则
SELECT本身就成了瓶颈
为什么预热失败时不能抛出异常
Hyperf在BootProcess::boot()中抛出未捕获异常会导致整个进程退出，服务无法启动。但缓存预热失败（如Redis临时不可达、某条SQL超时）不应阻断服务上线——它只是优化手段，不是功能依赖。
- 所有缓存操作必须包裹
try/catch，记录Logger::warning()而非error() - 不要在
boot()里调用sleep()或阻塞IO（如fopen远程文件），这会延长服务就绪时间，影响K8s探针检测 - 如果预热逻辑较重（如需加载上千条配置），考虑异步分批：用
go()协程发起，但不wait——允许主流程继续，让预热在后台渐进完成
预热逻辑越靠近真实请求路径越容易遗漏边界条件，比如多级缓存穿透、序列化方式变更导致反序列化失败——这些往往只在第一次业务请求时暴露，BootProcess里跑一遍并不能完全覆盖。
