在 Webpack 体系里处理 TypeScript 有两种常见路线：一种是直接用 ts-loader 调用 TypeScript 官方编译器，另一种是交给 babel-loader 做语法转换，类型检查则放到独立进程中完成。前者上手简单，但构建性能容易成为瓶颈；后者把两个职责拆开，更适合需要持续集成和大型代码库的场景。本文将围绕 Babel 与 Webpack 的配合展开，给出可落地的配置和优化思路。
为什么要把类型检查和代码转换拆开
TypeScript 编译器 tsc 每次处理文件时，既要检查类型是否匹配，又要把 TS 语法转换成目标 JavaScript。ts-loader 在 Webpack 中默认会对每个模块触发完整的 tsc 调用，这意味着即使只改了一个文件，构建过程也可能因为类型计算而拖慢。对于几十上百个模块的小项目感知不强，但模块数量达到数千时，编译时间会从秒级上升到分钟级。
Babel 处理 TypeScript 的思路完全不同：它只做语法层面的转换，也就是把类型注解、接口声明、泛型参数等内容直接移除，而不去验证这些类型是否合理。因此速度非常快，并且可以复用 Babel 生态里的插件和缓存机制。类型检查的职责可以单独交给 fork-ts-checker-webpack-plugin，它会启动一个独立进程运行 TypeScript 编译器，不影响主构建流程。
这种拆分还有一个好处，就是可以在开发环境持续获得类型错误提示，而不会因为类型检查失败阻塞打包。即使编辑器已经提示了类型问题，构建仍能产出可运行的 JavaScript，方便调试运行时逻辑。当然，生产构建前应确保类型检查通过，这可以通过 CI 环节单独执行 tsc --noEmit 来兜底。
配置 Webpack 与 Babel 转译 TypeScript
先安装必要的依赖：webpack、webpack-cli、babel-loader、@babel/core、@babel/preset-env、@babel/preset-typescript 以及 typescript。其中 @babel/preset-typescript 负责识别并剥离 TS 语法，@babel/preset-env 负责把现代 JavaScript 特性编译到目标环境。
module.exports = {
entry: './src/index.ts',
mode: 'development',
module: {
rules: [
{
test: /\.tsx?$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader',
options: {
presets: [
['@babel/preset-env', { targets: 'defaults' }],
['@babel/preset-typescript', { allowNamespaces: true }]
]
}
}
}
]
},
resolve: {
extensions: ['.ts', '.tsx', '.js']
}
};
上面配置的核心是给 babel-loader 指定两个预设。@babel/preset-typescript 的 allowNamespaces 选项允许 Babel 处理 namespace 语法，但要注意 Babel 对 namespace 的支持有限，实际项目中建议优先使用 ES module 的导入导出。如果代码里使用了 const enum，Babel 无法像 tsc 那样内联枚举值，需要改用普通 enum 或借助插件处理。
另一个常见问题是路径别名。如果 tsconfig 里配置了 baseUrl 和 paths，Webpack 的 resolve.alias 也要同步设置，否则 babel-loader 只负责语法转换，不会解析模块路径。可以借助 tsconfig-paths-webpack-plugin 来读取 tsconfig 的 paths 配置，减少重复维护。
接入独立类型检查
类型检查拆离的关键是 fork-ts-checker-webpack-plugin。安装后把它加入 plugins 列表，Webpack 会启动一个独立进程读取 tsconfig.json 并执行类型校验。主线程继续用 babel-loader 转译，两个过程并行，构建速度不会因类型计算而大幅下降。
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
module.exports = {
// entry、module、resolve 等配置同上
plugins: [
new ForkTsCheckerWebpackPlugin({
typescript: {
configFile: './tsconfig.json'
}
})
]
};
为了让独立检查更顺畅，tsconfig.json 里建议设置 noEmit: true，因为类型检查进程不需要输出文件。如果项目启用了 incremental 或 composite，可以加快增量检查速度。开发模式下还可以配合 eslint 集成，让插件同时检查 TypeScript 和 ESLint 问题，减少终端噪音。
性能优化方面，babel-loader 自身也支持 cacheDirectory 选项，开启后转译结果会写入磁盘缓存，二次构建时跳过未变化的模块。结合 Webpack 的 persistent cache，整体构建时间可以进一步降低。需要注意的是，独立类型检查进程虽然不影响转译，但首次启动仍会完整扫描项目，后续会基于文件变化做增量更新。
与 ts-loader 的对比及选型建议
ts-loader 和 babel-loader 的本质差异在于是否依赖 TypeScript 官方编译器做转译。ts-loader 调用 tsc，能完整支持所有 TS 语法，包括 const enum、namespace 合并等，且转译与类型检查一致，配置少。但它的速度取决于项目规模，并且需要额外设置 transpileOnly 才能获得接近 Babel 的转译性能，而 transpileOnly 又会关闭类型检查，必须搭配 fork-ts-checker-webpack-plugin 才能补回类型安全。
babel-loader 的优势是转译速度快、插件生态丰富，还能同时处理 JSX、装饰器等语法，适合已经使用 Babel 的项目逐步迁移到 TypeScript。但它不理解类型之间的关系，做不到跨文件类型推断，所以类型检查必须独立完成。此外，Babel 对 const enum 和 namespace 的某些用法不支持，这类代码需要改写成更标准的 ES 模块形式，或者改用 ts-loader。
选型时可以从团队技术栈和项目规模出发：如果是从零开始的 TypeScript 项目，并且构建性能优先，推荐 Babel + 独立类型检查；如果严重依赖 TS 特有语法，或者团队希望保持官方编译行为，ts-loader 加 transpileOnly 和类型检查插件也是成熟的方案。无论选哪种，核心原则都是把耗时的类型计算从主转译链路中分离出去。
WebpackTypeScriptBabel修改时间：2026-09-24 06:23:41