Node.js worker_threads数据共享与序列化安全

在Node.js多线程编程中，把数据扔给worker_threads处理，拿回来的时候发现数据不对劲，这是很多开发者踩过的坑。问题的核心在于，当我们通过postMessage传递数据时，底层用的是结构化克隆算法，这个算法在复制某些对象时会静默丢弃属性或者直接报错。比如你传一个包含Date对象的数据过去，接收端拿到的是字符串或者时间戳，而不是Date实例。再比如传一个Map或者Set，早期Node版本直接抛异常，现在虽然支持了，但里面如果存了不能序列化的值，照样出问题。这些都不是bug，是结构化克隆的设计限制。

结构化克隆算法有一套明确的支持列表。它能正确处理原始类型、普通对象、数组、ArrayBuffer、TypedArray、Map、Set、RegExp、Blob、File、ImageData这些。但它不支持函数、Symbol、WeakMap、WeakSet、DOM节点、以及任何原型链上的自定义属性。举个例子，你定义了一个类实例，通过postMessage传递后，接收端拿到的是个普通对象，原型链信息全部丢失，方法自然也没了。更隐蔽的问题是，如果对象上有getter/setter定义的属性，克隆时会触发getter取值，但setter不会跟着过去。这意味着你精心设计的响应式对象，到了Worker那边就变成了静态数据快照。

// 主线程
const { Worker } = require('worker_threads');

class User {
  constructor(name) {
    this._name = name;
  }
  get name() {
    return this._name.toUpperCase();
  }
}

const user = new User('alex');
console.log(user.name); // 'ALEX'

const worker = new Worker('./worker.js');
worker.postMessage({ user });
// Worker收到的是 { user: { _name: 'alex' } }，getter没了

不想复制数据，那就共享。SharedArrayBuffer是worker_threads里真正实现内存共享的机制。它允许主线程和Worker直接读写同一块内存，没有序列化开销，性能极高。但共享意味着并发问题。多个线程同时写同一个位置，结果不可预测。Atomics对象就是用来解决这个问题的，它提供了一组原子操作，保证读写在指令级别不被中断。比如Atomics.add可以在不被打断的情况下完成“读取-加值-写回”这个操作。但Atomics不是银弹，它只解决操作原子性，不解决复杂的业务逻辑同步。你如果用SharedArrayBuffer存一个复杂数据结构，比如手动管理内存布局，那出错概率极高，调试起来也极其痛苦。

// 主线程
const { Worker } = require('worker_threads');

const sab = new SharedArrayBuffer(1024);
const uint8 = new Uint8Array(sab);

const worker = new Worker('./worker.js', {
  workerData: { sab }
});

// 写入数据
uint8[0] = 42;

worker.on('message', () => {
  console.log('Worker修改后的值:', uint8[0]);
});

// worker.js
const { parentPort, workerData } = require('worker_threads');

const uint8 = new Uint8Array(workerData.sab);
// 原子操作加1
Atomics.add(uint8, 0, 1);
parentPort.postMessage('done');

SharedArrayBuffer还有一个安全层面的问题。2018年Spectre漏洞爆发后，浏览器端一度禁用了SharedArrayBuffer，Node.js虽然不受直接影响，但如果你在同一个进程里加载了不可信代码，SharedArrayBuffer可能成为侧信道攻击的载体。所以使用时要确保Worker里执行的代码是你自己控制的，不要随意加载用户提供的脚本到Worker里跑。

postMessage的序列化过程不是完全透明的。除了前面说的类型丢失，还有几个容易忽略的细节。第一是循环引用，结构化克隆支持循环引用，但如果你在对象里混了不能克隆的类型，整个序列化会失败。第二是Transferable对象，比如ArrayBuffer可以用transferList转移所有权，转移后原线程就无法访问了，这比复制快得多，但如果你的代码里还保留着对原ArrayBuffer的引用，后续操作就会出问题。第三是数据量，postMessage在底层会把数据完整复制一份，如果你传一个几百兆的对象，内存瞬间翻倍，甚至可能触发OOM。这时候应该考虑用SharedArrayBuffer或者把大文件拆成小块分批传递。

// Transferable示例：转移ArrayBuffer所有权
const buffer = new ArrayBuffer(1024 * 1024 * 100); // 100MB
const view = new Uint8Array(buffer);
view[0] = 1;

// 转移后主线程不能再访问buffer
worker.postMessage({ buffer }, [buffer]);

// 这里访问buffer会出问题，所有权已经转移
// console.log(view[0]); // 可能报错或得到未定义行为

很多人只用worker.postMessage，却忽略了MessageChannel。MessageChannel创建了一对相互连接的端口，你可以在主线程和Worker之间建立多条通信线路，把不同类型的数据分流。比如控制指令走一条通道，业务数据走另一条通道，这样不会因为大数据传输阻塞小消息的传递。更重要的是，MessagePort本身也可以被Transfer，你可以在多个Worker之间建立直连通道，让Worker之间直接通信，不需要主线程中转。这在大规模并发场景下能显著降低主线程压力。

// Worker之间直连通信
// 主线程
const { Worker, MessageChannel } = require('worker_threads');

const worker1 = new Worker('./worker1.js');
const worker2 = new Worker('./worker2.js');
const { port1, port2 } = new MessageChannel();

worker1.postMessage({ port: port1 }, [port1]);
worker2.postMessage({ port: port2 }, [port2]);

// worker1.js
const { parentPort } = require('worker_threads');

parentPort.on('message', ({ port }) => {
  port.postMessage('来自worker1的问候');
  port.on('message', (msg) => {
    console.log('worker1收到:', msg);
  });
});

Node.js对worker_threads的序列化支持一直在演进。Node 12之前，Map和Set不能直接传递。Node 12开始支持了Map、Set、BigInt。Node 15增加了对ArrayBuffer的转移优化。Node 18进一步完善了错误对象的序列化，Error的stack、cause等属性现在能正确传递了。如果你在生产环境用的是较老版本，升级Node本身就能解决一部分序列化问题。但要注意，不同版本之间Worker的数据交换格式是兼容的，因为结构化克隆是V8引擎层面的标准，不是Node自己定义的协议。

遇到结构化克隆不支持的类型，最常见的做法是手动序列化。比如用JSON.stringify和JSON.parse，但JSON也有自己的限制，不支持undefined、NaN、Infinity、循环引用。更好的选择是用v8模块的serialize和deserialize，它和结构化克隆用的是同一套底层机制，但允许你操作原始Buffer。这样你可以把序列化后的数据存到SharedArrayBuffer里，实现自定义的共享策略。还有一种方案是用MessagePack或者CBOR这类二进制序列化格式，它们在跨语言场景下更有优势，但纯Node.js环境里不如v8序列化高效。

const v8 = require('v8');

const data = {
  name: 'test',
  date: new Date(),
  map: new Map([['key', 'value']])
};

// 序列化
const serialized = v8.serialize(data);
// 现在serialized是Buffer，可以存到SharedArrayBuffer里

// 反序列化
const deserialized = v8.deserialize(serialized);
console.log(deserialized.date instanceof Date); // true
console.log(deserialized.map instanceof Map); // true

实际生产环境很少直接裸用Worker，一般会封装线程池。这时候数据共享策略要结合任务队列来设计。如果每个任务的数据都是独立的，用postMessage复制最安全，任务结束数据自动回收。如果需要多个任务共享只读数据，可以把数据加载到SharedArrayBuffer，然后每个Worker只读不写。如果任务之间需要交换中间结果，用MessageChannel建立Worker之间的通信网。还有一个容易被忽视的点是Worker的terminate。调用worker.terminate()会强制结束线程，但如果Worker正持有SharedArrayBuffer的引用，这块内存不会泄漏，因为SharedArrayBuffer由V8的GC统一管理，不受线程生命周期影响。

选哪种数据传递方式，本质上是时间换空间还是空间换时间的问题。postMessage复制：实现简单，内存隔离安全，但大数据量下内存和序列化开销大。Transfer转移：零拷贝，速度快，但转移后原线程失去访问权，适合一次性数据传递。SharedArrayBuffer共享：零拷贝且多线程可同时访问，但需要处理同步问题，调试复杂。实际项目中，大部分场景用postMessage就够了，只有遇到性能瓶颈才考虑后两种。判断标准很简单：如果你的数据超过10MB，或者每秒需要传递几十次以上，才开始考虑SharedArrayBuffer或者Transfer。过早优化只会增加代码复杂度。

worker_threads和浏览器Web Worker不同，Node的Worker可以访问系统资源，包括文件系统、网络、其他进程。不要把Worker当成安全隔离边界，它只是并发隔离。如果你需要在Worker里执行不信任的代码，应该用vm模块或者isolated-vm这类真正的沙箱方案。另外，通过postMessage传递的数据在主线程和Worker之间是值拷贝，修改不会互相影响，这天然提供了一定程度的数据隔离。但如果你用了SharedArrayBuffer，那就没有隔离可言，一个线程的越界写入会直接污染其他线程的数据。所以在使用SharedArrayBuffer时，建议用TypedArray的边界检查，或者自己封装一层访问接口，避免越界操作。

总结一下，worker_threads的数据传递核心就三条路：postMessage复制、Transfer转移、SharedArrayBuffer共享。结构化克隆的序列化限制是设计如此，不是缺陷，理解它的边界才能避免踩坑。性能优化从简单方案开始，够用就别上复杂方案。数据安全方面，复制天然隔离，共享需要自己管好边界。