Question 1

为什么 Vite 开发服务器在反复调用 server.restart() 时会发生内存泄漏，以及如何修复？

Accepted Answer

Vite 8.x 在每次 `server.restart()` 之后,会通过 `options.previousEnvironments` 保留已废弃的环境及其模块图,因为服务器的 init/listen 闭包使 options 对象保持可达。这种情况会跨多次重启形成链式引用,可能保留数百 MB 的堆内存,最终导致 Node 堆耗尽。修复方法:在 `_createServer`(`packages/vite/src/node/server/index.ts`)中,在等待环境初始化完成后,清除这个仅用于初始化阶段的引用:`options.previousEnvironments = undefined`。此时先前的实例已经传递给每个环境的 `init`,因此这样做是安全的。已在 Vite 8.3.0 和 8.1.4 上配合 Node 22/24/26 验证:已废弃环境的保留数量从 8/8 降为 0/8。请注意,Rolldown 中还存在一个独立的内存保留 bug(#10887),也必须一并修复,才能完整测量该内存泄漏。

Question 2

如何修复在启用 resolve.tsconfigPaths 的情况下，Vite 8 开发服务器中出现的 "Tsconfig not found" 错误？

Accepted Answer

当 Vite 的开发服务器使用合成的默认 importer（`<root>/index.html`），且没有任何 tsconfig 的 `include` 与之匹配时，就会发生这种情况，导致 tsconfig 自动发现机制向上遍历到父目录的 tsconfig.json，而该文件的 `extends` 无法解析（常见于嵌套的 git worktree 或 React Router 框架模式）。解决方法：在 Vite 配置中显式设置顶层 `tsconfig` 选项，将自动发现固定到项目的配置文件：

```ts
// vite.config.ts
export default defineConfig({
  tsconfig: './tsconfig.json',
  resolve: { tsconfigPaths: true },
})
```

或者，移除或修复父目录的 tsconfig.json（例如，在父目录中安装缺失的 `extends` 包，如 `@tsconfig/strictest`）。该 bug 会影响 `vite dev` 以及在没有 importer 的情况下调用 `transformRequest()` 的工具，如 `react-router build`/`react-router dev`。

Question 3

如何修复使用 Vite experimental.bundledDev 时出现的 'factory.fn is not a function' 或 "Cannot read properties of undefined (reading 'exports')" 错误？

Accepted Answer

这是版本不匹配问题：Vite 8.2.4 内置的 dev 客户端内联了 rolldown 1.2.4 的 DevRuntime，但 rolldown >= 1.2.6 更改了静态导入的 dev 产物生成方式，因此陈旧的运行时无法执行新的输出。修复方法：将 Vite 升级到 8.3.5 或更高版本（npm install vite@^8.3.5），升级后 Vite 会从已安装的 rolldown 中加载 DevRuntime，使生成器与运行时保持同步。如果必须继续使用 Vite 8.2.4，临时解决方案是：将 rolldown 固定到 1.2.5（npm install rolldown@1.2.5 或在 package.json 中配置 override），因为 1.2.5 的产物仍与内联的运行时匹配。

Question 4

如何修复在使用 Yarn 4 和 `nodeLinker: pnpm` 时，运行 `yarn install` 后 Vite 不重新打包依赖的问题？

Accepted Answer

出现这种情况是因为 Yarn 4 在使用 `nodeLinker: pnpm` 时，既不会创建 `node_modules/.yarn-state.yml` 也不会创建 `.pnp.cjs`，因此 Vite 对一个空的 lockfile 进行哈希（`lockfileHash: e3b0c442...`），并继续使用过期的预打包依赖。

临时解决方案：

```bash
npx vite --force
```

或者在启动开发服务器之前删除 Vite 的依赖缓存：

```bash
rm -rf node_modules/.vite/deps && npx vite
```

如需自动化的解决方案，可以添加一个 `postinstall` 脚本：

```json
{
  "scripts": {
    "postinstall": "rm -rf node_modules/.vite/deps"
  }
}
```

永久修复：在 `packages/vite/src/node/optimizer/index.ts` 中修改 Vite 的 `lockfileFormats`，在现有的 Yarn 条目之后添加回退到源 lockfile 的配置：

```ts
{ path: 'yarn.lock', checkPatchesDir: '.yarn/patches', manager: 'yarn' }
```

或者，将 Vite 升级到包含 `fix(optimizer): fall back to yarn.lock for lockfile hash` 更改的版本。

Question 5

如何修复 Vite 开发服务器在 Windows 上崩溃并报 "EBUSY: resource busy or locked, watch" 错误的问题？

Accepted Answer

根本原因：Vite 的开发服务器订阅了 chokidar 的 `change`/`add`/`unlink` 事件，但从未订阅 `error` 事件，因此任何 watcher 故障（短暂锁定文件导致的 EBUSY、EPERM、ENOSPC、inotify 配额耗尽）都会变成未捕获的异常，从而杀死整个进程。在 Node 24.16.0+ 上更容易遇到此问题，因为 libuv 1.52 现在以读取权限打开被监视的文件（一个典型触发场景：Vite 根目录内的 ASP.NET `bin/` 文件夹，其中刚编译好的 DLL 仍处于锁定状态）。在核心修复发布之前的临时解决方案：

1) 通过 `vite.config.js` 中的插件附加你自己的错误处理器：
```js
export default {
  plugins: [{
    name: 'watcher-error-guard',
    configureServer(server) {
      server.watcher.on('error', (err) => console.error('Watcher error (ignored):', err))
    }
  }]
}
```

2) 排除被锁定的构建输出，使 chokidar 永远不会对其调用 `fs.watch()`：
```js
export default { server: { watch: { ignored: ['**/bin/**', '**/obj/**'] } } }
```

3) 将 Node 固定在 24.16.0 以下（libuv < 1.52），以避免刚写入、仍被锁定的文件触发 EBUSY。

正式修复（Vite 为 FSWatcher 附加 `error` 监听器）正在进行中；上游 libuv 的回归问题在 libuv/libuv#5270 跟踪。

vite

项目简介

README 预览

常见问题 (5)

同类型项目

hermes-agent

firecrawl

go

markitdown