企业官网建设流程全解析

1. 问题定位：先分清"真不执行"还是"假不执行"

接手过Vue项目的人，十有八九都栽过Worker的跟头。你按教程写好new Worker(...)，控制台不报错，页面也不崩溃，但里面的代码就是静悄悄的一点动静都没有。我最开始做技术排查时，也被这个现象坑过好几回，一度怀疑是不是浏览器禁用了Worker。

先理清楚一件事：Worker代码"不执行"通常分两种情况。一种是连Worker线程都没创建成功，构造函数直接就抛异常了，这种情况反而好定位，控制台会有明确的报错信息；另一种是Worker线程创建成功了，但你的代码根本没跑进去，或者跑进去就退出了，这种情况最隐蔽，也是大多数"代码不执行"问题的真面目。

判断是哪一种，教大家一个最土但最有效的办法：在Worker文件的第一行写一个毫不相关的副作用，比如往控制台打个console.log('worker alive')，或者更狠一点，直接抛一个全局错误看它冒不冒出来。

// worker.js 第一行 console.log('worker alive'); throw new Error('worker boot');

如果这个错误能被页面的worker.onerror捕获到，说明Worker本身是通的，问题出在你传给Worker的代码逻辑或加载方式上；如果连错误都捕获不到，赶紧回头检查Worker的加载路径和构建配置。这一招能过滤掉至少一半的无效排查时间。

还有一点容易被忽略：浏览器同源策略对Worker的限制比普通脚本严格得多。线上环境如果页面在https://下，但Worker文件通过http://加载，浏览器会直接拒绝执行。本地开发时这种情况少见，真正上线后就容易冒出来。我之前帮人排查一个前端工程化项目的页面白屏，查到最后才发现是部署的CDN域名和页面域名协议不一致，Worker被拦在门外了。

2. 排查清单：照着顺序查，不走弯路

2.1 路径问题：最常见的元凶

Worker文件路径堪称第一坑。在Vue组件里写new Worker('./worker.js')，这个路径是相对当前页面的URL解析的，不是相对你的Vue组件文件，更不是相对项目目录。单页应用的路由一嵌套，路径全乱套了。

以某一次我处理"某跨平台系统"为例，路由地址是/dashboard/report，页面里创建Worker时写的相对路径./worker.js，浏览器解析出来的实际请求地址直接变成了/dashboard/report/worker.js，服务器返回404，Worker自然就"不执行"了。

正确做法是分场景处理：

• 开发环境：Vue-cli和Vite都推荐把Worker文件放在public目录下，然后用绝对路径/worker.js创建，这是最稳的方案。
• 生产环境：如果项目部署在域名子路径下（比如https://example.com/app/），/worker.js会解析到域名根目录，同样404。Vite可以用import.meta.env.BASE_URL拼接，Vue-cli用publicPath配置处理。

// Vite 环境下的安全写法 new Worker(`${import.meta.env.BASE_URL}worker.js`) // Vue-cli 环境下的安全写法 new Worker(`${process.env.BASE_URL}worker.js`)

还有一个很多人不知道的细节：Webpack5原生支持new Worker(new URL('./worker.js', import.meta.url))这种写法，打包时会把Worker文件当作独立资源处理，路径自动搞定，不需要手动管。Vite对new URL这种写法也兼容，不过我更推荐直接用?worker后缀导入，等会儿会细说。

2.2 构建工具的配置问题：Vite和Vue-cli各说各话

路径没问题后，下一个嫌疑就是构建工具。很多人换了构建工具后Worker就失灵，多半是没搞清楚两种工具处理Worker的方式完全不同。

Vue-cli环境（Webpack4以下），Webpack本身不认new Worker()这种写法，直接打包会把这个调用原样留在代码里，浏览器运行时才去动态加载。如果你的Worker文件放在了src目录下，打包后这个路径是不存在的，代码自然不执行。解决办法是装worker-loader并配置：

// vue.config.js module.exports = { configureWebpack: { module: { rules: [ { test: /\.worker\.js$/, use: { loader: 'worker-loader' } } ] } } }

然后引入时加.worker后缀，触发loader处理：

import Worker from './my.worker.js' new Worker()

Vite环境就省心多了，直接在组件里这样写：

import MyWorker from './worker?worker' const worker = new MyWorker()

Vite会把?worker后缀的文件当作Worker打包，自动处理URL和代码分割。就算Worker文件在src目录下也没问题。

Vue3项目如果用的是Vite，强烈建议用?worker方案，省去路径的烦恼。Vue-cli改成Webpack5之后也支持new URL写法，升级后可以顺手把旧方案换掉。

2.3 Worker内部不能碰的东西

代码真的进了Worker函数体，还是没效果，那就要检查是不是碰到Worker的禁区的。Worker线程没有window和document，DOM操作一概不能做。有人图省事直接在Worker里操作状态管理的全局变量或者引用了外部的window.config之类的数据，结果全部是undefined，代码执行到一半就静默失败了。

比如这样一段代码，放在主线程里跑得好好的，搬进Worker就出问题：

// 无法执行的写法 self.onmessage = (e) => { const token = window.localStorage.getItem('token') // Worker里没有window fetch('/api/data', { headers: { Authorization: token } }) }

在模块化项目里，Worker文件如果用了ES Module语法，还要确认构建工具是否做了兼容处理。老版本Webpack打包出来的Worker文件是普通脚本，里面不能用import，用了就直接语法错误。Vite对ES Module支持得不错，但在Safari等部分浏览器上还有兼容性坑，具体可以查can i use。

Worker只能拿到的全局对象是self。所有需要的外部数据，通过postMessage传给它。这是Worker的设计哲学，也是新手最不习惯的地方。

3. 核心细节解析：从创建到通信的链路拆解

3.1 Worker创建阶段：三种方式怎么选

Worker的创建方式有三种，工程化场景下要按项目情况选对：

第一种是刚才提到的字符串或URL直连，适合原型验证，路径写死，项目稍微一改造就脆断。

第二种是new URL模式，Webpack5和Vite都支持，路径交给构建工具解析，不会出现路由嵌套乱path的问题。缺点是部分老构建工具要升级配置。

第三种是?worker后缀导入（Vite）或worker-loader（Webpack）。这是最工程化的方式，Worker文件作为独立模块受构建工具托管，天然支持代码分割和资源hash。缺点是Worker文件不能再走普通脚本逻辑，必须当作模块处理。

我个人的选型经验是：

• Vue3 + Vite：无脑?worker
• Vue2 + Vue-cli4：worker-loader
• Vue2 + Webpack5（升级后）：new URL跟import.meta.url

选型时还要考虑一件事：项目的Worker有多少。只做一个任务队列（比如图片压缩），怎么创建都无所谓；但如果你要跑十几个不同类型的独立任务，强烈建议把Worker统一放一个目录，按功能拆分文件，别把一堆postMessage逻辑塞进一个入口文件，否则后面维护起来看都不想看。

3.2 Worker文件内部：onmessage和postMessage的配对

链路是创建成功 ->worker.postMessage()发消息 -> Worker内部通过self.onmessage接收 -> 处理完成后再self.postMessage()回传 -> 页面里通过worker.onmessage接收结果。这条链路只要有一个环节断了，代码表现出来的就是"不执行"。

新手最常见的问题，是消息配对对不上。比如页面里用worker.postMessage({ type: 'start', payload: data })，Worker里却在判断e.data === 'start'。{ type: 'start' }是对象，永远不等于字符串'start'，看起来就是Worker没反应。

规范的写法是给消息定义类型约定：

// 页面侧 worker.postMessage({ type: 'compress', data: file }) // Worker侧 self.onmessage = async (e) => { const { type, data } = e.data if (type === 'compress') { // 执行压缩逻辑 self.postMessage({ type: 'compressed', result }) } }

通信调试技巧：在onmessage入口先打印e.data，确认收到的内容跟预期一致再往下走。我Debug时养成习惯了，每次新写业务消息都先打一梭子，排查速度飞快。

3.3 Worker内再发异步请求：注意上下文变化

Worker里面发fetch请求是允许的，但要注意异步回调里容易丢失上下文。有人会图省事在Worker里写：

self.onmessage = (e) => { const result = someGlobalFunction() self.postMessage(result) }

结果someGlobalFunction在Worker上下文里压根不存在。所有依赖函数都要在Worker文件内定义或显式引入，不能用主线程作用域里闭包出来的内容。

3.4 子线程的错误处理：别让异常静默吞掉

Worker里的逻辑只要有一行抛出异常，后续代码全部止步。而默认情况下，Worker进程里的异常不会像主线程那样直接标红在页面上，它是通过error事件传播的。如果你没监听worker.onerror，异常就真的石沉大海了。

排查时建议先在Worker里包一层try/catch：

self.onmessage = async (e) => { try { const result = await handleData(e.data) self.postMessage({ status: 'ok', result }) } catch (err) { self.postMessage({ status: 'error', message: err.message }) } }

页面侧再统一监听错误事件：

worker.onerror = (err) => { console.error('Worker错误:', err.message) }

这样即便出错，也能快速定位是哪一个环节出问题。很多人调Worker调到头秃，就是因为错误信息全被静默了。

4. 实操过程：从零到一跑通一个图片压缩Worker

光讲原理没用，照着走一遍才是正道。下面用一个完整的Vue3 + Vite项目Demo演示，需求是：把用户上传的图片在Worker里压缩，再回传结果。

4.1 新建Worker文件

在src/workers目录下新建compress.worker.js：

// 引入图片压缩库 import imageCompression from 'browser-image-compression' self.onmessage = async (e) => { const { file, options } = e.data try { const compressedFile = await imageCompression(file, options) self.postMessage({ status: 'done', file: compressedFile }) } catch (error) { self.postMessage({ status: 'error', message: error.message }) } }

4.2 在组件里创建Worker并通信

<template> <input type="file" @change="handleUpload" /> </template> <script setup> import CompressWorker from '../workers/compress.worker?worker' let worker = null function handleUpload(event) { const file = event.target.files[0] if (!file) return worker = new CompressWorker() worker.onmessage = (e) => { const { status, file: compressed, message } = e.data if (status === 'done') { console.log('压缩完成', compressed) } else { console.error('压缩失败', message) } worker.terminate() } worker.onerror = (err) => { console.error('Worker异常:', err) worker.terminate() } worker.postMessage({ file, options: { maxSizeMB: 0.5, maxWidthOrHeight: 800 } }) } </script>

4.3 常见误区排查记录

场景一：压缩库在Worker里import时报错。检查是不是库本身依赖了DOM API。browser-image-compression内部用了canvas相关API，Worker里没有DOM API。这个库理论上不能直接在Worker里跑，这是我踩过的坑。这时候要么换一个纯JS实现的压缩方案，要么把这种库拆到主线程用OffscreenCanvas处理。别指望Worker里什么都能干。

场景二：文件从主线程传给Worker后变成了空对象。postMessage采用结构化克隆（structured clone），File、Blob、ArrayBuffer这些对象能正常传。但如果传的是封装过的类实例，原型链会丢失，变成普通对象。传文件就传File本身，别传封装对象。

场景三：页面路由跳转后Worker还在跑，甚至报错。路由销毁时必须回收Worker，否则线程一直挂着。在Vue3的onBeforeUnmount里线worker.terminate()，再把worker置空。

这些经验都是在实际项目里用代价换回来的。每次排查到最后一个环节，回头看往往就是路径少写了个斜杠，或者消息字段名差了个字母。

5. 常用调试技巧与避坑口诀

5.1 Debug的五板斧

• 看网络面板：F12切到Network，刷新页面，看Worker文件有没有加载，状态码是多少，200还是404，这一步能排除一半的路径和服务器配置问题。
• 看控制台 Filter：Chrome控制台有Worker过滤项，切换后可以看到Worker线程自己的console输出。Worker里的console.log默认不会混在主线程日志里，容易忽略。
• 断点下到Worker文件里：Sources面板能直接给Worker文件打断点，不需要额外配置。
• 用debugger声明：在Worker文件里直接写debugger;，有时候比断点更省事，配合条件判断可以精准暂停到特定业务分支。
• 看任务管理器：Chrome自带浏览器任务管理器能查看每个Worker线程占用的CPU和内存。如果页面里创建了Worker但没看到对应线程，说明创建都失败了；线程在但CPU为0，说明它在空转或提前无人响应。

5.2 避坑口诀

一切路径以浏览器最终请求地址为准。不要信源码里写的相对路径，要看Network面板里真实发出去的URL。

Worker是个独立的小世界，没有window、没有document、没有主线程定义的任何变量。所有依赖都要自备，数据全靠postMessage流动。

错误信息一定要捞出来。Worker的异常默认静默，不捞就等于瞎调。统一在onerror和onmessage里做兜底。

5.3 动态创建和销毁的正确姿势

大型应用里Worker不要一直活着，该销毁就销毁：

• 耗时任务完成后调用worker.terminate()释放内存
• 路由离开前在钩子函数里终止对应Worker
• 频繁创建Worker的场景要注意浏览器对线程数量的限制（每个页面通常最多几十个Worker），用完就归还

可以让Worker内部处理完消息后自动执行self.close()：

self.onmessage = (e) => { // 业务逻辑 self.postMessage(result) self.close() }

这样避免Worker内隐式持有的闭包引用泄漏。

5.4 用了Vuex/Pinia的注意点

很多人想在Worker里直接访问Vuex或Pinia的状态。这里明确一下：不行。状态管理库依赖Vue响应式系统，Worker线程里压根没有Vue实例。正确做法是：

• 主线程发起任务时，把需要的状态字段通过postMessage一并传过去
• Worker处理完，把结果回传主线程，主线程再commit到store

这个模式调整之后，状态来源单一，也不容易出现跨线程的引用问题。我接手的某跨平台系统最初就想把store直接传进Worker，后来发现方案完全不可行，改为消息传递后逻辑清爽多了。

6. 最后再分享一个提高排查效率的小技巧

如果项目里的Worker代码反复出现"不执行"，建议从项目架构层面自查一下：是不是把过多的业务逻辑塞进了Worker，导致Worker文件越来越像个莫名其妙的混合体？我见过一个模拟项目，Worker文件里既有接口请求、又有数据转换、还有状态判断，将近两千行，排起错来那叫一个欲哭无泪。

我的习惯是：Worker的职责保持单一，一个Worker只做一个类型的事，文件尽量控制在300行以内。如果业务复杂，拆成多个Worker，用主线程做轻量调度。比如图片处理一个Worker，数据加密一个Worker，计算密集型任务一个Worker。这样任何一个环节出问题，几分钟就能定位到具体文件。

还有就是版本升级后多留意构建工具的变更日志。Webpack5带来new URL支持、Vite调整过?worker的实现细节，框架越来越省事是真，但"表面省事"也容易让人忽略底层行为变化。遇到Worker不执行，第一反应不要怀疑API用错了，先怀疑构建产物跟你以为的形态不一样。

调试Worker的过程说穿了就三件事：确认文件加载、确认线程存活、确认消息配对。三步走完，九成问题已经浮出水面。剩下的要么是禁区操作，要么是依赖缺失，按上面的排查清单逐项过一遍，基本都能解决。