在使用 Node.js 构建需要长时间运行的后台服务时，事件循环阻塞是一个容易被忽视但后果严重的性能问题。Inngest 在其 Connect 产品的开发过程中遭遇了典型案例：用户代码的 CPU 密集计算导致心跳无法发出，服务器误判 worker 已死亡并停止分发任务。这一问题的解决思路与生产落地参数对于类似场景具有直接参考价值。
事件循环饥饿的典型成因
Node.js 的事件循环按阶段依次处理任务： timers 阶段执行 setTimeout 与 setInterval 回调，I/O 阶段处理网络与文件系统操作，随后是 setImmediate 与 close callbacks。关键特性是每个阶段的回调必须全部执行完毕才会进入下一阶段，期间如果存在同步阻塞代码，整个循环将停滞。这意味着一个执行 30 秒的同步函数会同时阻止定时器触发、网络数据接收以及其他所有预定工作。
具体到 Inngest 的场景，Connect 维护着与 Inngest 服务器的持久 WebSocket 连接，通过该连接接收函数调用并定时发送心跳以证明 worker 存活。当用户代码执行 CPU 密集型操作（如图像处理、数据转换或复杂计算）时，主线程的事件循环被完全占用，setInterval 设置的心跳回调无法在预定时间执行。服务器在多次心跳超时后判定 worker 已断开，进而将任务路由至其他实例，导致用户看到 no available worker 错误。标准建议是避免在主线程执行阻塞操作，但在运行不受控的用户代码场景下，这一原则难以强制遵守。
Worker threads 的隔离价值与实现路径
Node.js 的 worker_threads 模块允许在同一进程内创建独立的 V8 隔离实例，每个 worker 拥有独立的堆内存和独立的事件循环。关键特性是：一个 worker 中的 CPU 密集型代码不会阻塞另一个 worker 的事件循环。这为关键系统功能与用户代码的隔离提供了技术基础。
Inngest 的解决方案是将 Connect 的内部组件（WebSocket 连接、心跳、重新连接逻辑、认证握手）全部迁移至 worker 线程，而用户代码的执行保持在主线程。两者通过 postMessage 进行消息传递：WebSocket 帧从 worker 转发至主线程执行，执结果再传回 worker 返回给服务器。这种架构使得即便主线程被用户代码长期占用，worker 线程的心跳依然能够准时发出，服务器得以正确识别 worker 的存活状态。
生产落地的关键参数
基于 Inngest 的实践经验，以下参数适用于类似场景的 worker threads 部署。线程数量方面，由于每个 worker 占用约 10 MB 内存且启动成本在数十毫秒级别，worker 线程适合长期运行而非频繁创建销毁。线程池大小通常设置为 CPU 核心数的 50% 至 100%，即 4 核机器建议 2 至 4 个 worker，同时需结合单 worker 内存占用与总可用内存进行调优。心跳间隔建议设置为 10 至 30 秒，具体取决于上游服务的超时策略，Inngest 采用 10 秒间隔以确保快速故障检测。消息队列大小需根据并发任务量设置，建议监控队列深度以防止积压。
重连与恢复策略方面，worker 线程可能因未捕获异常、V8 内存溢出或网络故障而终止。主线程必须监听 exit 事件并实现带指数退避的自动重启：首次退出立即重试，后续每次退出的等待时间翻倍，上限通常设为 30 秒至 60 秒。成功建立连接后重置退避计数器。日志传输需要特殊处理，由于用户传入的 logger 对象无法通过结构化克隆算法序列化传递给 worker，worker 线程应发送结构化日志条目（级别、消息、上下文）至主线程，由主线程调用用户的 logger 进行输出。
需要特别注意的约束条件
Node.js worker threads 与其他语言的并发原语存在本质差异，团队需在设计阶段充分考虑。首先，无法将函数直接传递至 worker：结构化克隆算法不支持函数序列化，new Worker () 必须指向一个文件路径，这意味着每个 worker 都是独立入口的独立程序，通信必须预先设计为消息协议。其次，消息传递存在序列化开销：对象、数组、TypedArray 等数据在主线程与 worker 之间会被深拷贝，大负载场景下需评估性能影响，若需共享原始内存可考虑 SharedArrayBuffer 与 Atomics，但适用场景有限。第三，Bundler 静态分析无法发现 worker 文件：Webpack 5+ 仅在使用 new Worker (new URL ("./worker.js", import.meta.url)) 这一特定语法时才能检测到 worker 文件，任何间接调用都会导致构建遗漏。对于库开发者，需将 worker 文件显式添加为构建入口点。
监控与可观测性要点
生产环境中 worker threads 的监控应聚焦以下指标。线程存活状态方面，主进程需持续检测 worker 的在线状态，可通过定期发送 ping 消息并验证响应来实现，响应超时（建议 5 秒）触发告警与重连。事件循环健康状态可通过在 worker 内部设置独立的定时器自我检测，若心跳延迟超过阈值（如正常间隔的 150%）则触发告警。内存使用方面，监控每个 worker 的堆内存增长趋势，异常增长可能暗示内存泄漏。进程退出事件需记录 exitCode 与 signal 信息，用于根因分析，频繁退出的 worker 需触发深入排查。
综合评估与适用场景
Worker threads 为 Node.js 应用提供了事件循环隔离的有效手段，特别适用于以下场景：需要维护持久连接（如 WebSocket、Server-Sent Events）且无法容忍主线程阻塞的服务；需要运行不受控的第三方代码且必须保证系统基础功能正常运作的后台任务处理框架；CPU 密集型计算需与 I/O 操作并行执行且希望避免进程间通信开销的架构。在这些场景下接受 worker threads 带来的额外开发成本（消息协议设计、bundler 配置、生命周期管理），能够获得其他方案难以提供的隔离强度。
资料来源：本文核心实践案例来自 Inngest 技术博客《Node.js worker threads are problematic, but they work great for us》，该文详细记录了 Connect 产品解决事件循环饥饿问题的完整技术路径。