onfinish回调的第一个参数是$task对象，包含任务id、原始数据、工作进程id及finish方法，用于接收异步任务处理结果。
onFinish 回调必须显式设置才能接收任务结果
不设 onFinish，哪怕 task() 投递成功、$task->finish() 正常调用，结果也直接丢弃，Worker 进程里完全收不到。Swoole 启动时会校验：只要配置了 task_worker_num > 0，就必须同时注册 onTask 和 onFinish，否则 $server->start() 直接失败并抛出致命错误。
task() 的 $finishCallback 参数会绕过全局 onFinish
在 Worker 进程中调用 task() 时传入第 3 个参数 $finishCallback，该回调会在 Task 完成后**立即在当前 Worker 进程内执行**，不再走 onFinish 流程。这意味着：
- 这个回调函数不能访问
$server实例（除非闭包里 use 进来，但要注意生命周期） - 它和
onFinish是互斥的：一个任务只能走其中一种返回路径 - 常见误用：在
$finishCallback里又调用$server->push()却没检查连接是否还存活，导致警告或崩溃
task_worker_num 和 onFinish 触发时机强相关
onFinish 只在 Master 进程收到 TaskWorker 的完成通知后触发，而这个通知依赖 IPC 通道。如果 task_worker_num 设得太小，任务排队积压，onFinish 就会明显延迟——不是回调写得有问题，是任务根本还没处理完。
可通过 $server->stats() 实时观察关键指标：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
tasking_num：正在跑的任务数，持续接近task_worker_num就说明满负荷 -
task_queue_num：队列里等处理的任务数，> 0 就代表有延迟风险 -
task_pop_count - task_push_count为负？说明有任务丢失或未正确 finish
onFinish 第一个参数不是原始 data，而是 $task 对象
很多人以为 onFinish($server, $task_id, $data) 的 $data 就是当初 task($data) 传进去的内容，其实不是。Swoole 4.5+ 版本中，onFinish 的签名是 onFinish($server, $task_id, $data)，但这里的 $data 是 $task->finish($data) 传入的返回值，和投递时的 $data 无直接关系。原始投递数据得从 $task 对象里取（如果用了对象投递方式），或者你得自己在返回值里带上上下文字段。
真正安全的做法是：
- 在
onTask中把原始$data和处理结果一起打包进$task->finish() - 比如
$task->finish(['origin' => $data, 'result' => $handled]) - 然后在
onFinish中解包使用，避免歧义
这个细节在升级 Swoole 版本后特别容易踩坑，尤其是从 4.4 升到 4.8+ 时，$data 含义变了但文档没强调。
