阻塞主线程有时是对的：什么任务应该留在主线程执行
现代 Web 开发有一条几乎神圣的规则：永远不要阻塞浏览器主线程。几乎所有性能指南都在强调它，这确实是好建议。主线程是单线程的，同一时刻只能做一件事，而且它不只属于你——浏览器渲染引擎、输入处理器和其他关键任务都在上面排队。主线程被占用的时间越少，应用响应越快。
但这条规则不是绝对的。作者 Victor Ayomipo 在开发 Chrome 截图扩展 Fastary 时发现，有时候把数据移交给 Worker 处理，反而比让主线程直接干活更慢。
浏览器上下文隔离的架构
浏览器不只有一个环境。多个环境同时运行，各自拥有独立的内存空间和访问规则：
- 主线程：JavaScript 逻辑、DOM、样式渲染和用户交互所在的地方；
- Web Worker：独立线程，可以执行 JavaScript 但没有 DOM 访问权，通常用于处理重数据任务；
- Service Worker：网络代理，拦截网络请求，页面关闭时也能运行；
- Chrome 扩展上下文：后台 Service Worker、内容脚本和 Offscreen Document。
这些上下文彼此隔离，无法直接读取对方的变量，这就是"共享无状态"（shared-nothing）架构。它们之间靠 postMessage() 这类 API 显式传递消息。
postMessage 与结构化克隆算法
postMessage() 让浏览器把一段数据交给目标上下文，底层依赖结构化克隆算法（Structured Clone Algorithm，SCA）。你可以把它理解为 JSON.stringify() 的更强化版本：一个深度的递归拷贝过程，遍历整个数据结构、克隆每个值、序列化后传输到目标端再重建。
对小对象（比如 {theme: "dark"}）这个过程可以忽略不计。但处理大数据时故事就不同了——SCA 是同步阻塞的 O(n) 操作，成本随数据量线性增长。
想象一个场景：用户点击按钮，内部把一张 8MB 的图片交给后台 Worker 处理。调用 postMessage() 时，主线程必须立即停下当前工作，完成序列化和拷贝。如果打包、传输、解包再回到起点的时间，比在主线程上直接处理数据还长，那为什么不直接在主线程做？
Transferable 对象：快但有限制
追求极致性能的开发者会用 Transferable 对象（如 ArrayBuffer、ImageBitmap、MessagePort）绕过结构化克隆。转移对象时不拷贝，而是把数据所有权从一个上下文切换给另一个——发送方立即失去访问权，接收方完全接管。
这确实极快。根据 Chrome 开发者基准测试，转移一个 32MB 的 ArrayBuffer 不到 7ms，而克隆约需 300ms，快约 43 倍。
但它有代价：数据送出去就没了，如果 UI 还需要展示预览就访问不到了；并非所有数据都可转移（普通 JS 对象、Blob、Base64 字符串都不行）；API 也有限制——浏览器扩展的 chrome.runtime.sendMessage 传统上强制走 JSON 序列化，所以对 Fastary 来说 Transferable 对象根本不可用。
Fastary 案例：推荐的架构反而是错的
作者的 Fastary 扩展目标是像原生应用一样即时响应。他采用了推荐做法：用 Offscreen Document 在后台处理 DOM 和 Canvas 操作（裁剪、拼接截图、加水印），架构是：后台 Service Worker 用 captureVisibleTab() 截图得到 Base64 data URL → 用 chrome.runtime.sendMessage() 把图片传给 Offscreen Document → Offscreen Document 加载到 img、绘制到 canvas、应用裁剪坐标、编码后把结果传回。
测试时却持续有 2-3 秒延迟。原因：1080p 屏幕的截图 Base64 字符串约 1MB 以上，Retina 屏还会默认加倍；而扩展消息依赖 JSON 序列化，图片数据至少被序列化两次——进去一次、带结果出来一次。真正在 Offscreen Document 里做的裁剪处理非常快，慢的是传输开销。
结论：什么时候隔离，什么时候不隔离
作者总结出一个心智模型，取决于任务是哪种类型：
计算密集任务（CPU-Bound）：主要成本是计算本身而非数据大小，比如图片压缩、音频分析、物理模拟。这类任务传输成本相比实际工作微不足道，后台处理是明确赢家。
数据密集任务（Data-Bound）：恰好相反。只有因为数据量大才贵，处理时间几乎可忽略，比如图片裁剪、数组过滤、浅拷贝。这种情况下把任务挪到后台往往属于"负和效率"——移动几 MB 数据只为执行一个 50ms 的操作，没有任何收益。
可以这样估算：
总时间 = 序列化成本 + 传输 + 后台处理时间 + 反序列化成本
如果"后台处理时间"占绝对主导，隔离是赢家；如果序列化加反序列化加传输超过处理成本，就没必要隔离。分不清任务属于哪类时，动手测量最稳妥——用 performance.mark() 和 performance.measure() 围绕 postMessage 调用分析传输成本。
那条"永远别阻塞主线程"的规则，更准确的表述是"不要长时间阻塞主线程"。
来源：When It Makes Sense To "Block" The Main Thread - Smashing Magazine