Vite 8 开发时 Worker 收到 HTML：检查依赖预构建改写的包路径

开发页面提示 Could not create web worker(s)，Worker 请求状态却是 200，响应正文以 HTML 开头。若同一项目的生产构建正常，检查这个 URL 是否在依赖预构建后多出了一层库目录。

Vite 8.3.4 的明确触发条件是：一个被预构建的 ESM 库使用 new Worker(new URL('包名/worker.js', import.meta.url), ...)，其中字符串是裸包路径。优化器把它按库文件的相对路径重定位；正常 Worker 解析器本来还有按包查找的机会，错误改写先把这条机会截断了。

先认出错误的目录关系

下面是结构示例，包名仅作占位：

// fake-lib 的 ESM 入口
export const start = () => new Worker(
  new URL('fake-dep/worker.js', import.meta.url),
  { type: 'module' },
);

应用需要安装并能解析 fake-dep 的 worker 子路径。若开发请求变成 /node_modules/fake-lib/fake-dep/worker.js，磁盘上却只有 /node_modules/fake-dep/worker.js，应继续查看 /node_modules/.vite/deps/ 中实际交给浏览器的库代码。

比较源码、预构建响应和 Worker 请求三个位置。返回 HTML 可能只是 SPA fallback 接到了不存在的资源，不能因为 HTTP 200 就认定 Worker 已加载。若 URL 正确而响应因登录跳转或服务器配置变成 HTML，应处理那个响应链，不属于这次路径改写。

ESM 库可评估局部绕开预构建

确认库及其浏览器入口可以直接作为 ESM 执行后，在原配置里排除产生 Worker 表达式的库：

import { defineConfig } from 'vite';

export default defineConfig({
  optimizeDeps: {
    exclude: ['fake-lib'],
  },
});

替换为实际包名，保留其他配置。这里排除的是持有表达式的库，不是随意把 Worker 文件或整个依赖树排除。若该入口实际是 CommonJS，就不能采用这个绕行；ESM 内部依赖 CommonJS 时，也要按该依赖的真实格式保留所需转换。

保存原配置、依赖清单和锁文件，重启开发服务并通过原启动入口强制更新预构建缓存。若 dev 脚本直接运行 Vite，可传 npm run dev -- --force；框架封装的命令应按其参数规则处理。

不要给表达式随手加 /* @vite-ignore */。它会影响后续静态识别，可能让开发暂时改变行为，却令生产 Worker 不再被打包。也不要在 node_modules 中手工补同名空文件，那种结果无法由锁文件重建。

Worker 真正运行才算恢复

开发环境中检查最终 URL、JavaScript 响应内容与 Worker 的实际消息或任务结果，再单独运行项目原生产构建和预览，确认 Worker 资源被交付且能执行。开发排除只改变优化阶段，不能代替生产验收。

上述限制在已核对的 Vite 8.3.4 正式优化器中仍存在；不能因问题已关闭便承诺这个版本已修。若局部排除不适合项目，保留当前可工作的依赖组合，等待并核对正式修复后用同一条包路径回归。撤回临时配置时恢复配置与锁文件，并重新生成开发缓存。