vite启动卡在“pre-bundling dependencies”是因ts配置与依赖分析冲突所致；需删.vite/deps并--force重试，再严格限制tsconfig.include/types、排除cjs/esm混用包及动态require依赖。
Vite 启动卡在开发服务器阶段，尤其是卡在 Pre-bundling dependencies 或长时间无响应，通常不是网络或硬件问题，而是 TypeScript 配置与 Vite 依赖分析机制发生冲突所致。核心要抓住“类型声明参与预构建”和“TS 编译范围失控”这两个关键点。
先快速验证是不是预构建卡住
终端停在 “Pre-bundling dependencies” 不动、CPU 拉满、.vite/deps 目录为空或只生成部分文件，就是典型预构建卡死。
- 删掉
.vite/deps（注意：不是node_modules） - 运行
vite --force强制重做预构建 - 如果仍卡住，临时在
vite.config.ts中加optimizeDeps: { disabled: true }，再启动——若能成功，说明问题确实出在预构建环节
检查 tsconfig.json 是否把不该扫的路径全扫进来了
Vite 在预构建时会读取 tsconfig.json 的 include 和 types 字段，一旦配置过宽，就会触发冗余扫描甚至死循环。
-
include应严格限定为源码路径，例如：["src/**/*.ts", "src/**/*.d.ts"]，避免写["**/*.ts"]或包含tests、types、mocks等非运行时路径 -
compilerOptions.types只保留真正影响运行时类型推导的包，比如"vue"、"vite/client"；移除"jest"、"cypress"、"@types/node"（除非你真在浏览器里用 Node API） - 确认
compilerOptions.paths没指向node_modules子目录（如"@utils/*": ["node_modules/my-utils/src/*"]），这类别名会让 Vite 尝试解析第三方内部路径，极易卡住
排查混用 CJS/ESM 或动态 require 导致解析失败
Vite 默认以 ESM 方式处理依赖，遇到 CommonJS 特有语法（尤其是未被拦截的 require('./xxx')、__dirname、process.env）可能直接卡死或报错。
- 检查
package.json中是否同时存在lodash（CJS）和lodash-es（ESM），这类“灰色地带”包是常见冲突源 - 留意是否有依赖用了
electron、sqlite3、老版本axios插件等含条件导出但未适配 ESM 的库 - 可在
vite.config.ts的optimizeDeps.exclude中明确排除可疑包，例如：exclude: ['electron', 'sqlite3']
用插件定位耗时模块（尤其针对 SCSS/Less 编译慢）
有时卡顿并非来自 JS 依赖，而是样式文件编译阻塞主线程——特别是单个 SCSS 文件 import 链过深、含大量嵌套或 @import 全局变量。
- 安装
vite-plugin-inspect，在 vite 配置中引入它 - 启动
vite dev后，命令行会输出一个 inspect 页面地址 - 打开该页面，查看各模块加载耗时，重点观察
.scss、.less文件及其依赖链，找到最慢的那一个 - 确认该样式是否真的需要在启动时全部编译（比如来自 UI 库的完整样式包），考虑改为按需引入或提取为 CSS 文件
不复杂但容易忽略：很多卡顿本质是 TS 配置和 Vite 分析逻辑的隐式耦合，而不是代码本身的问题。盯住 tsconfig.json 和 optimizeDeps 这两处，基本就能定位八成以上启动卡顿原因。
