HTML本身没有多线程，浏览器通过Web Worker、SharedArrayBuffer、OffscreenCanvas等机制实现并发；主线程负责DOM、渲染与事件循环，Worker则隔离执行耗时任务，但需注意通信开销、跨域隔离要求及API限制。
HTML 本身没有多线程——这是个常见误解。所谓“HTML多线程”实际是指在浏览器环境中，通过 Web Worker、SharedArrayBuffer 或 OffscreenCanvas 等机制实现的并发能力，它们确实能缓解页面卡顿，但有严格前提和限制。
为什么主线程卡顿，而 Web Worker 不卡？
浏览器的 DOM 操作、事件循环、样式计算、布局、绘制全在主线程执行；任何耗时 JS（比如大数组排序、复杂 JSON 解析、加密运算）都会阻塞它，导致页面冻结。而 Web Worker 运行在独立线程，无法访问 document、window 或 DOM，只靠 postMessage 通信，天然隔离了渲染压力。
- 必须用
new Worker('path/to/worker.js')加载独立 JS 文件，不能直接传函数或箭头函数 - Worker 内不能调用
console.log（部分浏览器支持，但行为不一致），建议用postMessage回传日志再在主线程打印 - 频繁
postMessage大对象（如 10MB 数组）会触发结构化克隆，开销不小；可改用Transferable（如ArrayBuffer）零拷贝传递
SharedArrayBuffer 配合 Atomics 能真共享内存吗？
可以，但仅限于同源、且需开启跨域隔离（COOP + COEP 响应头）。否则 SharedArrayBuffer 构造会直接抛错：SharedArrayBuffer is not defined 或 SharedArrayBuffer constructor is not available。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须在服务端返回响应头：
Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp -
Atomics.wait()在主线程不可用，只能在 Worker 中调用，否则报Atomics.wait cannot be called in this context - 不要用
SharedArrayBuffer存对象或字符串——它只支持Int8Array、Float64Array等视图，存复杂数据得自己序列化/反序列化
OffscreenCanvas 能把 Canvas 渲染搬出主线程吗？
能，但仅限 2d 上下文（webgl 支持有限且浏览器差异大）。关键点在于：Canvas 元素本身仍需挂载在 DOM，但绘图逻辑可完全移入 Worker，通过 transferControlToOffscreen() 获取离屏实例。
立即学习“前端免费学习笔记（深入）”；
- 必须先在主线程创建
<canvas>，再调用canvas.transferControlToOffscreen()，返回OffscreenCanvas实例 - 该实例只能传给 Worker（用
postMessage(..., [offscreenCanvas])），且传入后原<canvas>就不能再调用getContext('2d') - Worker 中拿到的
OffscreenCanvas支持完整2dAPI，但不支持toDataURL()、toBlob()——若需导出，得把像素数据用getImageData()提取后传回主线程
真正影响卡顿的从来不是“有没有多线程”，而是数据怎么切、通信频率是否合理、以及是否误以为 Worker 能操作 DOM。很多团队加了 Worker 却更卡，问题往往出在主线程反复解析大消息，或 Worker 里做了本该由 GPU 加速的图像处理——这些地方，线程切换成本反而高于直接优化算法或换用 requestIdleCallback 分片执行。
