如果你在开发过程中遇到“Vite 能跑但 TS 报错”。而一样代码在 Webpack 中报错导致项目无法启动，那就不是工具本身的问题，而是它们对 TypeScript 的处理方式不同。说起来，

Vite这方面，默认不会做 TypeScript 类型检查

Vite 默认使用 esbuild 来处理 .ts/.tsx 文件。而 esbuild 只做：

说到例如，

let a: string = 123;console.log，

执行后会被 esbuild 转成：

let a = 123;console.log，

浏览器可以运行，但编辑器会给出红色波浪线提示。例如 “Type 'number' is not assignable to type 'string'”。

为什么 Vite 能跑？

因为 Vite 在启动时只关心快速编译，故不做类型检查；这让热更新更快，

Webpack 为什么经常不行？

Webpack 本身也不会检查 TS，但实际情况取决于你使用的 Loader。不过，

ts-loader

{ test: /.ts$/。loader: "ts-loader" }

ts-loader 会执行：

于是会报错，导致项目启动失败。

开启 transpileOnly 时怎么办？

{ loader: "ts-loader"。options: { transpileOnly: true } }

此时 ts-loader 只转 JS，不检查类型，与 Vite 的行为一致。怎么说呢，

Babel Loader

// Babel + @babel/preset-typescript
// 转换流程：TS → babel-loader → @babel/preset-typescript
// 最终输出纯 JS
let a: string = 123;不过，// 被转成 let a = 123;老实说，

Babel + TypeScript 与 Vite + esbuild 行为基本一致。

真正负责检查 TS 的是谁？

The real type checker is always TypeScript compiler itself:

• NPM 脚本方式：

{
"scripts": {
至于"dev"。"vite","build": "vite build","type-check": "vue-tsc --noEmit"
}
}

• 开发时： "vite" 快速启动，**不**检查 TS。

• 提交代码前： "npm run type-check" 检测所有类型错误。话说回来，

为什么 Vite 要这样设计？

• DPR的观点是。TypeScript 类型检查非常慢，例如大型项目可能需要几秒钟；而 esbuild 在几十毫秒内完成转换。话说回来，

Preset : esbuild 默认 ❌ 不检查 ❌ 不阻止仍可运行

Preset : ts-loader 默认 ✅ 检查 ✅ 通常会阻止编译

Preset : ts-loader ❌ 不检查 ❌ 不阻止仍可运行

Preset : tsc / vue-tsc --noEmit ✅ 检查 ✅ 报告所有错误 \t\t\t\t\t\t <\/tbody> <\/table>

现代 Webpack 项目如何与 Vite 相近？怎么说呢，

- 大型项目往往采用 fork‑ts‑checker‑webpack‑plugin 或者单独的 tsc 命令来做异步、后台类型检查。以保持编译速度，- 例如配置示例：

webpack –>
|-- babel-loader –>
|-- fork-ts-checker-webpack-plugin –>
单独线程检查 TS

<\/pre>

- 或者直接在 CI 中执行 npm run type-check。-\t这样，现代 Webpack 与 Vite 的思路已越来越接近：编译与类型检查解耦。其实，-\t这让开发者既能享受快如闪电的热更新，又能保持严格的类型安全。-\t最终确保只有通过了全量类型校验的代码才会进入生产建立阶段。-\t这样既提高了开发效率，也降低了上线风险。-\t所以如果你在某个项目里看到“Vite 可以跑却报错”，而“Webpack 启动失败”。那并非工具本身的问题，而是两者使用不同的 TypeScript 编译链路所致。"