先记住这个答案
Web Worker 由浏览器调度为真实操作系统线程，拥有独立的全局作用域（DedicatedWorkerGlobalScope）和独立事件循环。主线程与 Worker 之间通过 postMessage 异步通信并携带结构化克隆后的数据，因此耗时的同步计算在 Worker 线程中执行时，不占用主线程的 JavaScript 执行时间，主线程仍可处理渲染、输入等事件，页面保持响应。
- Worker 运行在独立 OS 线程，与主线程并行。
- 消息传递是异步且结构化克隆数据的。
- 主线程仍专责渲染与 UI 事件，不被计算挤占。
独立线程与事件循环的协作机制
现代浏览器通常为每个标签页分配独立的渲染进程（同源标签页有时会共享进程），其中主线程运行渲染和 JavaScript。Web Worker 由浏览器启动为独立线程，其代码不会被嵌入主线程的调用栈。当主线程创建 Worker 并执行 postMessage 时，只是把一个消息放入 Worker 线程的任务队列，Worker 线程会在自己的事件循环中取出消息并执行对应回调。
关键在于两个事件循环完全独立：主线程处理页面渲染、用户输入和大多数 DOM 回调，而 Worker 运行脚本逻辑。若在 Worker 中执行 while 循环，该循环消耗的是 Worker 线程的 CPU 时间，页面主线程的任务队列照常推进，因而不会出现 JavaScript 阻塞导致的页面冻结。
处理大规模数组排序的工程场景
假设一个网页要排序百万级记录，若在主线程调用 Array.prototype.sort，该同步操作会占用主线程几秒钟，期间滚动、点击均无响应。采用 Worker 时，主线程创建一个 sortWorker，向其 postMessage 原始数组（通过结构化克隆传副本），随后注册 onmessage 回调。主线程马上可以继续响应用户操作，Worker 在后台执行排序并回传结果。
该方案中，主线程读取返回值必须依赖异步消息，无法同步获得排序结果。若业务逻辑需要等待排序完成再更新 UI，通常会在主线程使用 Promise 包装 onmessage，仅当收到回传消息后才更新列表。这种做法将同步等待转移为异步回调，把主线程从长阻塞中解放出来。
失效条件与适用边界
Web Worker 不阻塞主线程有前提：Worker 代码本身不能访问 DOM，且通信必须通过异步消息。若在主线程 worker.onmessage = ... 后仍写一个巨大的同步循环，主线程照样卡死。另外，结构化克隆对于大数组（如数十 MB 的 ArrayBuffer）有拷贝开销，可能使 postMessage 本身就耗时几十毫秒，但该时间发生在主线程调用 postMessage 的同步阶段。
要减小拷贝开销，应使用 Transferable 对象。当 postMessage 指定 transfer 数组后，ArrayBuffer 的所有权被移交，主线程原引用失效，不再拷贝整个缓冲。但注意，转移后原变量不可再用，若需主线程再次访问必须等 Worker 回传另一个 ArrayBuffer。例如在处理大文件解析时，可把文件缓冲直接转移给 Worker 处理。
容易答错的地方
- Worker 代码与主线程完全隔离，不会碰 DOM
- Worker 确实无法直接操作 DOM，但常误以为所有 Window API 都不可用。实际上 Worker 拥有部分浏览器能力，如
fetch、WebSocket、IndexedDB，只是不能触碰document、window及布局相关对象。这种设计避免了线程安全问题，但并非切断一切。 - 创建 Worker 后所有计算都会自动不阻塞主线程
- 如果你在主线程的
onmessage回调中又加入大循环，回调执行时主线程还会被阻塞。Worker 只是提供了一个允许耗时逻辑运行的执行环境，主线程自身代码仍须保持轻量。否则即使有 Worker，主线程也会因自身繁重任务而失去响应。
面试官还会怎么问？
两个 Worker 同时往主线程发送消息时，消息顺序能保证吗？
不同 Worker 发送到主线程的消息，其到达的相对顺序不能保证，调度由浏览器决定。若业务依赖先后，应让各消息携带序列号或时间戳，在主线程汇总后重排。而同一个 Worker 连续发出的多条消息，会按发送顺序进入主线程的任务队列，这一先后顺序是可以依赖的。
Worker 中执行的任务太耗时，需要终止时怎么办？
主线程可调用 worker.terminate() 立刻终止 Worker，该线程正在执行的同步任务会被中断，不再占用线程资源。但终止是强制的，Worker 内无法捕获终止信号，可能造成部分数据状态未持久化。所以尽量避免依赖内部清理逻辑。
为什么创建 Worker 的第一步通常检查全局对象是否可用？
因为某些环境（如旧浏览器或某些 WebView）可能不实现 Worker 接口。在 typeof Worker === 'undefined' 时选择降级方案，可避免运行时错误。这种防御式检测能保证在不支持时仍用主线程执行计算，只是会退化到阻塞模式。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。