默认 cluster.schedulingPolicy 在 macOS/Windows 为 SCHED_NONE，导致连接集中到首个 worker；Linux 为 SCHED_RR 故较均衡。应显式设置 cluster.schedulingPolicy = cluster.SCHED_RR。
Node.js 单进程默认只跑在一个 CPU 核心上，cluster 模块是官方提供的、最轻量且可靠的方式，让服务真正吃满多核 CPU —— 但它不是开箱即用的“自动负载均衡器”，核心在于主进程（master）分发连接，而非请求。
为什么 cluster.fork() 后请求没均匀打到各 worker？
常见现象：启动 4 个 worker，但 curl 连续压测时，只有 1–2 个 worker 的 console.log 有输出，CPU 使用率也明显不均。这是因为默认的 cluster.schedulingPolicy 在不同系统行为不一致：
-
Linux 默认是
cluster.SCHED_RR（Round-Robin），按连接轮询分发，表现接近均衡 -
macOS 和 Windows 默认是
cluster.SCHED_NONE，由内核决定，实际常导致连接全落在第一个 worker 上
解决方法很简单，在 cluster.isMaster 分支中显式设置：
cluster
-
process.send()和process.on('message')：适合小数据、低频事件（如配置热更、日志汇总） - 外部存储：Redis、PostgreSQL 等——任何需要共享状态（session、缓存、任务队列）的场景，必须走外部服务
- 文件系统（不推荐）：竞态、性能差、无原子性保障
特别注意：cluster.worker.send() 是向指定 worker 发消息，而 process.send() 在 worker 中调用时，目标是 master；在 master 中调用则需传入 worker 实例。方向搞反会导致静默失败。
重启 worker 时如何避免请求丢失？
直接 worker.kill() 或 process.exit() 会立刻断开已建立的连接。正确做法是：
- worker 收到
SIGUSR2（或其他自定义信号）后，停止接受新连接：server.close() - 等待已有连接自然结束（可设超时，如 30s），或主动调用
server.getConnections()监控活跃连接数 - 确认无活跃连接后再退出：
process.exit(0) - master 监听
'exit'事件，立即cluster.fork()替换
这个流程必须自己编码控制，cluster 模块本身不提供优雅退出逻辑。
真正难的不是 fork 几个进程，而是处理好连接生命周期、状态隔离和信号协调——这些地方出错，往往表现为偶发超时、数据不一致或服务抖动，排查起来比单进程复杂得多。
