类型检查适合放入 Web Worker，因其为纯计算、无副作用、不依赖主线程 API；需静态导入校验库或传 schema 描述重建逻辑，注意数据序列化限制与错误处理。
类型检查与验证这类操作通常阻塞主线程，尤其在处理大型数据结构或复杂 schema 时。把它们移进 Web Worker，能避免 UI 卡顿，提升响应性。
为什么适合放进 Worker
类型检查（如用 zod、io-ts 或自定义校验逻辑）本质是纯计算：输入数据 + 规则 → 输出结果（通过/失败 + 错误信息）。它不依赖 DOM、localStorage、window 等主线程专属 API，也没有副作用，天然适合隔离执行。
- Worker 独立线程，运行时不影响渲染和用户交互
- 可复用同一套校验逻辑（只需序列化规则与数据）
- 支持 postMessage 传递结构化克隆对象，包括嵌套对象、数组、基本类型
如何传递校验逻辑到 Worker
不能直接传函数或 class（无法序列化），需提前在 Worker 内部定义或动态 import 校验器。
- 推荐方式：Worker 中静态 import 校验库（如
import { z } from 'zod'），并在 onmessage 中调用 - 若需动态 schema，可将 schema 描述（如 JSON Schema 或 zod 的
safeParse所需的 schema 序列化形式）传入，Worker 用对应解析器重建校验逻辑 - 避免传大量代码字符串 + eval，既不安全也不利于 tree-shaking
注意数据传递的边界
postMessage 只能传可结构化克隆的对象。函数、Date、RegExp、Map、Set、Blob 等会被丢弃或转为 {} / null。
- 传入数据前，先做轻量预处理：如把 Date 转成 ISO 字符串，Map/Set 转为数组
- 校验结果中若含 error.stack 或自定义 error 类实例，需手动扁平化为 plain object
- 大对象（如百 MB 级 JSON）建议用 Transferable（如 ArrayBuffer）分块传输，但类型校验一般不需要
错误处理与调试技巧
Worker 内报错不会触发主线程 window.onerror，容易静默失败。
- Worker 中加 try/catch，统一返回 { success: false, error: message }
- 开发时可在 Worker 里 console.log，配合 Chrome 的 “Workers” 面板查看输出
- 主线程监听 worker.onerror，并 fallback 到同步校验（降级保障）
不复杂但容易忽略：校验逻辑本身要足够轻量引入，避免把整个框架打包进 Worker；一次校验耗时超过 100ms 就值得考虑 Worker 化。
