vite冷启动慢主因是ts和依赖处理,优化需聚焦预构建、路径解析与类型检查:显式配置optimizedeps、统一tsconfig与alias、分离tsc监听、按需加载插件、限制文件监听范围。

Vite 的冷启动慢,多数不是 Vite 本身的问题,而是项目规模变大后,TypeScript 和依赖处理环节拖慢了首次 dev server 启动。优化重点不在“重装工具”,而在精准控制预构建、路径解析和类型检查节奏。
精细配置依赖预构建(最直接见效)
Vite 启动时会扫描 node_modules 并预构建所有用到的依赖,但很多包根本不会在开发阶段被加载。盲目预构建反而拖慢启动。
- 显式声明真正需要预构建的包,比如:
optimizeDeps: { include: ['vue', 'vue-router', 'pinia', 'lodash-es', '@element-plus/icons-vue'], exclude: ['moment-timezone', 'xlsx'], // 已通过 CDN 引入或纯运行时用的包 } - 若项目模块多、入口分散(如多页面应用),补充
entries指定预构建起点:entries: ['./src/main.ts', './src/entry-admin.ts']
- 还可借助
vite-plugin-optimize-persist自动生成最优include列表,避免手动维护遗漏。
统一并精简路径别名(减少重复解析)
TS 的 paths 和 Vite 的 resolve.alias 必须严格一致,否则会导致同一模块被多次解析、缓存失效。
- 在
tsconfig.json中:"baseUrl": ".", "paths": { "@/*": ["src/*"], "@api/*": ["src/api/*"] } - 在
vite.config.ts中同步:resolve: { alias: { '@': path.resolve(__dirname, 'src'), '@api': path.resolve(__dirname, 'src/api') } }这样能避免 Vite 在 resolve 阶段反复遍历目录,尤其对大量
import '@/xxx'的项目提速明显。
分离 TypeScript 类型检查与构建流程(不卡主线程)
Vite 默认用 esbuild 转译 TS(只做语法转换,不校验类型),而类型检查由 tsc --noEmit 或 IDE 独立完成。若你在启动时还跑 tsc --watch 或 vue-tsc --watch,它会抢占资源、延长感知启动时间。
- 开发时关闭自动类型检查监听(除非必要);
- 使用
tsc --noEmit --watch --skipLibCheck单独后台运行,不阻塞 Vite 启动; -
tsconfig.json中开启关键提速项:"skipLibCheck": true, "incremental": true, "composite": true, "tsBuildInfoFile": "./.tsbuildinfo"
这些能让后续启动复用类型缓存,大幅缩短二次冷启动时间。
按需启用插件,避免开发阶段加载构建专用插件
有些插件(如 vite-plugin-compression、rollup-plugin-visualizer、unplugin-auto-import 的某些模式)只在 build 阶段有用,却在 dev 时也初始化,白白消耗内存和 CPU。
- 使用条件加载:
plugins: [ isBuild && viteCompression({ threshold: 5120 }), !isBuild && vue(), ].filter(Boolean) - 或更稳妥地用
apply: 'build'/apply: 'serve'明确作用域。
合理设置文件监听范围(减少 FS 压力)
Vite 默认监听整个项目目录,但 node_modules、dist、.git、日志等无需热更新。
- 在
vite.config.ts中限制:server: { watch: { ignored: ['**/node_modules/**', '**/dist/**', '**/.git/**', '**/logs/**'] } }尤其当项目含大量
.d.ts或生成代码时,这项能显著降低 chokidar 的开销。
不复杂但容易忽略











