闭包无法直接传入 Worker Threads，因其无法被结构化克隆；应只传纯参数、ArrayBuffer（transferList 零拷贝）或预加载逻辑模块，避免深拷贝与重复函数创建。
闭包本身不能直接传入 Worker Threads——因为线程间不共享内存，所有数据必须通过 postMessage 显式传递，而闭包（含函数、外部作用域变量、this 绑定等）无法被结构化克隆（structured clone），会被序列化为 null 或直接报错。所以所谓“闭包的变量复制开销”，实际是**你试图把本该封装在闭包里的状态，强行塞进可传输的数据结构中所引发的隐式拷贝、重复构造或逻辑割裂问题**。
哪些看似“闭包变量”的东西会悄悄触发深拷贝？
开发者常误以为只要把计算逻辑抽成函数、再把依赖参数打包传过去就安全了，但以下情况会让性能大幅下滑：
-
传对象字面量但含大量嵌套或循环引用：比如
{ config: deepConfig, data: hugeArray }，即使没函数，postMessage默认走结构化克隆，对 5MB 的数组会完整复制一份到子线程堆内存 -
用 JSON.stringify + parse 模拟“传闭包”：有人把配置+原始数据转成字符串再传，子线程里
JSON.parse还原——这看似规避了序列化限制，实则多了一次解析开销，且丢失类型（Date变字符串、Map变空对象） -
在线程内重建闭包式逻辑：比如主线程有
const makeProcessor = (threshold) => (item) => item > threshold，你传threshold进去，子线程再重新定义这个函数——看似轻量，但每次新建函数实例、V8 需要重新编译优化，高频调用时不可忽视
真正该传什么？三类推荐模式
不追求“还原闭包”，而是按用途选最轻量、最可控的数据形态：
-
纯参数：只传原始值或扁平对象
例如：
worker.postMessage({ n: 1000000, mode: 'fast', precision: 6 })—— number/string/boolean/简单 object 都是零成本拷贝（V8 内部优化过） -
大数组/缓冲区：用 ArrayBuffer + transferList 零拷贝
例如：
const buf = new SharedArrayBuffer(1024 * 1024); worker.postMessage(buf, [buf]);—— 不复制内容，只移交所有权，子线程可直接读写同一块内存（需手动同步） -
逻辑复用：把“闭包行为”固化为线程内模块
例如：Worker 脚本里直接
import { fastFilter } from './utils.js'，主线程只传data和options，避免把策略逻辑当数据传
怎么验证你有没有掉进“伪闭包陷阱”？
别猜，用工具看真实开销：
- 在主线程发消息前打点：
const t0 = performance.now(); worker.postMessage(data); console.log('post cost:', performance.now() - t0)—— 若超过 1–2ms，大概率是传了大对象 - 在线程入口加
console.time('init')，看从收到消息到真正开始计算耗多久 —— 若明显延迟，说明JSON.parse或对象重建占了时间 - 用
process.memoryUsage()对比线程启动前后：如果heapUsed突增几十 MB，基本确认发生了意外深拷贝
本质上，Worker Threads 不支持闭包传递不是缺陷，而是设计使然。接受这个约束，把“状态+行为”拆开：状态走数据通道，行为走代码预加载，才能稳住性能底线。
