说起来，

我们有一个桌面应用的项目技术栈是 Tauri + Vue3 + Vite。

每次 dev 冷启动，终端已经打出 Running app.exe 了窗口还要再等一分多钟才出来慢的时候将近 100 秒。按理说，

但进程一旦起来改代码 HMR 又很快。一两秒就刷新，

开发体验很差于是决定排查一下原因看能不能调整一下。

确定时间花在哪？

先在前端埋两个点，用 @tauri-apps/plugin-log 输出到日志文件：

perfLog)}ms`);// 入口模块求值完
perfLog)}ms`);说起来，// 真正 show 窗口

perfNow 是 performance.now从 WebView 导航开始算。跑出来这方面，

window.show perfNow=92548ms

92548 毫秒 ≈ 92 秒！

秒，而 mount 本身只有几十毫秒。时间没花在业务代码上，是花在把入口模块图加载完之前。

是前端还是服务端慢？

用 curl 直接打 Vite，带上 DEBUG=vite:time 看每个请求的耗时。冷启动按顺序打几个端点：

@/vite/client .8s
/src/main.ts .9ms
/src/styles/index.scss .0s
/src/styles/tailwind.css .26ms

是个静态文件。不用编译，也要 0.8 秒；里就一行 @use,也 0.0 秒。

每个新进程启动都有一笔十几到几十秒的一次性开销。付完之前的请求全卡着，付完之后同进程就都快了。冷启动慢、HMR 快就是这么来的——HMR 是同一个进程，这钱早付过了。

Curl 不走 WebView 也能复现。 所以是 Vite 服务端的问题，跟 Tauri、WebView2 无关。

走了个弯路-怀疑杀软

"每个进程第一次很慢、之后很快、数值还忽高忽低"，这表现挺像杀毒软件实时扫描的。我去 Defender 加了项目目录排除，后来干脆把实时保护关了重测。

结果还是 ~100 秒！没有任何调整，说起来，

CPU profiler

没头绪了AI 提示抓个 CPU profile 看看。按理说，用 Vite 的 JS API 起服务，配 inspector 给冷的 transformRequest 采样，比 curl 干净。不受端口和 WebView 干扰：

const server = await createServer
await server.listen
await server.transformRequest

Vite dev 在 createServer 的时候就用 chokidar 递归监听整个项目根，在 Windows 上走 fs.watch，一个目录一个目录、一个文件一个文件地建监听句柄。

而我们项目根下有个 /src-tauri/target/​...好几个 G、几万个文件，也被一起递归注册了。这些句柄的注册在启动时就开始铺；server.listen 又不等它做完，早来的请求都卡在这场遍历后面。那笔几十秒的开销就是它，

问题确认后怎么修改呢？

"让 Vite 别去监听这个目录"

同一个 transformRequest 前后对比：

结果 * /@vite/client: 从 ~16 s 降到 ~1 s * /src/main.ts: 从 ~33 s 降到 ~0.35 s * /src/App.vue: 从 ~44 s 降到 ~1 s

实际 pnpm dev 冷启动时“window.show”从约 100 秒 降至 ~5–7 秒。

前端 HMR 和 Rust 重编都不受影响：忽略的是建立产物；说起来，前端仍然热更新，Rust 那边有自己的 watcher，与 Vite 前端这套是分开的。其实，

如果你遇到 Tauri+Vue+Vite 开发环境冷启动极慢。请检查项目根下是否存在大目录如 /src-tauri/target/​…​/.gitignore‑style list>。通过 watch.ignore='**/src-tauri/target/**' 或类似方式忽略掉即可明显提高冷启动速度。