node repl 无法测试 cluster 互斥锁定，因其单进程、无 ipc、无主从角色分离，cluster.fork() 直接报错；需用多脚本、最小 cluster 文件或 child_process.fork 模拟验证。
Node REPL 本身不支持直接 fork 子进程或运行 cluster 模块的完整主从逻辑，因为 REPL 是单进程交互式环境，无法启动真正的多进程集群。Cluster 模块依赖于进程派生（cluster.fork()）、IPC 通信和主/从角色分离，这些在 REPL 中均不可用——它没有 process.argv 上下文、不区分 isPrimary / isWorker，也无法持久监听端口或响应 exit / listening 事件。
为什么 REPL 不能测试 cluster 互斥锁定
互斥锁定（如防止多个 worker 同时写同一文件、更新共享计数器）需满足三个前提：
- 多个独立 worker 进程真实存在并并发运行
- 它们通过
process.send()和process.on('message')或共享内存（如 Redis）协调 - 主进程能监听并中转消息，或使用外部同步服务（如 mutexify + Redis）
REPL 只有一个进程、无 IPC 环境、无事件循环隔离，所有代码都在同一上下文中执行。即使手动 require('cluster')，cluster.isPrimary 恒为 false，cluster.fork() 会直接抛错：Error: Cannot fork in REPL。
可行的替代验证方式
若目标是快速验证互斥逻辑（例如“同一资源不被两个 worker 重复处理”），推荐以下轻量级方法：
-
用两个独立 Node 脚本模拟 worker：分别运行
node worker-a.js和node worker-b.js，通过文件锁（fs.open(..., 'wx')）、Redis SETNX 或mutexify实现跨进程互斥，再在终端并发触发 -
在最小 cluster 文件中加调试日志：写一个
test-cluster.js，启动 2 个 worker，在每个 worker 处理请求前尝试获取 Redis 锁，失败则 log “locked out”，成功则执行并释放——用curl并发请求即可观察互斥效果 -
用
child_process.fork()手动模拟：主脚本用fork()启两个子进程，通过 IPC 发送任务 ID，主进程用 Map 记录已处理 ID 并广播拒绝，比 cluster 更底层但可在单文件内调试
简单可运行的互斥验证示例（非 REPL）
保存为 mutex-test.js，用 node mutex-test.js 运行：
const http = require('http');
const { Mutex } = require('async-mutex'); // npm install async-mutex
// 全局互斥锁（仅主进程持有，worker 通过 IPC 请求）
let globalMutex;
if (cluster.isPrimary) {
globalMutex = new Mutex();
for (let i = 0; i } else {
http.createServer(async (req, res) => {
const release = await globalMutex.acquire(); // 实际需通过 IPC 调用主进程
console.log(`[Worker ${process.pid}] got lock`);
await new Promise(r => setTimeout(r, 100));
release();
res.end(`OK from ${process.pid}`);
}).listen(3000);
}
注意：上面的 globalMutex 不能直接跨进程共享，真实实现需主进程暴露 IPC 接口，worker 发送 lock 消息并等待回复——这正是 REPL 无法承载的环节。
