onWorkerStart 在 Swoole v4.4.0 之后才正式支持
很多人以为 onWorkerStart 是从 v3 就稳定可用的，其实不是。v3.x 系列（包括 v3.4）压根没这个回调；它最早出现在 v4.4.0 的 beta 版本中，并在 v4.5.0 后成为稳定接口。如果你在 v3 升级到 v4 时发现 onWorkerStart 不触发，先确认是否真的跑在 v4.4+ 上——php --ri swoole 看一眼版本号最直接。
- v3.x：只有
onStart、onWorkerStop，没有onWorkerStart - v4.4.0～v4.5.x：支持但部分参数行为不一致（比如
$worker_id在 task 进程里可能为 -1） - v5.0+：语义更清晰，
$worker_id在 worker/task 进程中均有效，且onWorkerStart不再被onTask或onReceive调用时机干扰
为什么 v4.4 之前不能用 onWorkerStart
根本原因是 v3 和早期 v4 的进程模型里，worker 进程启动逻辑是“隐式加载”的：代码文件在主进程里 require 一次，然后 fork 出 worker，没有独立的“worker 初始化钩子”。直到 v4.4 引入了显式的 onWorkerStart 回调，才把 worker 级别的初始化（如数据库连接、Redis 实例、全局缓存预热）从 onStart 里剥离出来。
-
onStart只在 master 进程执行一次，不适合初始化单进程独占资源 - 以前有人在
onReceive里做连接池懒加载，结果扛不住突发流量，连接数暴涨 - v4.4+ 的
onWorkerStart才真正让“每个 worker 拥有自己的一套连接”变得自然可控
onWorkerStart 在 v4 和 v5 中的参数与行为差异
v4.5 到 v5.0 的主要变化不在函数签名，而在底层调度逻辑——这直接影响你写什么、怎么写。
- 参数始终是
function (Swoole\Server $server, int $worker_id)，没变 - v4.x 中，task 进程也会触发
onWorkerStart，但$worker_id可能为 -1（尤其在task_enable_coroutine关闭时） - v5.0+ 明确区分：
$worker_id >= 0表示普通 worker，$worker_id 表示 task 进程（如 -1、-2），且 <code>onWorkerStart在 task 进程中默认不执行，除非显式设置'task_worker_num' => N并启用task_enable_coroutine - v5 默认开启协程，所以你在
onWorkerStart里可以直接用Co\MySQL或Co\Redis，而 v4.x 需要确保已调用Swoole\Coroutine::set(['hook_flags' => SWOOLE_HOOK_ALL])
常见踩坑点：onWorkerStart 里做了不该做的事
这个回调看着像“每个 worker 启动时执行一次”，但实际运行环境比想象中敏感。
- 不要在
onWorkerStart里做阻塞 IO（比如 file_get_contents 本地配置文件），v5 默认协程环境下会直接报错 “cannot use blocking io in coroutine” - 别在
onWorkerStart里 new 大量对象或加载大文件，它会在每个 worker 启动时重复执行，内存占用翻倍 - 如果用了 Laravel/Symfony 等框架，别直接在
onWorkerStart里require vendor/autoload.php—— 它已在主进程加载过，重复加载会触发类重定义警告 - 注意
onWorkerStart不是“仅执行一次”，worker 进程异常退出后重启，它还会再执行一遍；所以初始化逻辑得幂等（比如数据库连接要判断是否已存在）
最容易被忽略的是：v4.4 引入的 onWorkerStart 并不自动帮你隔离协程上下文，v5 也没替你做连接复用——该自己管理连接池的，还是得自己管。
