TypeScript 动态导入中如何正确处理 .ts 扩展名？

TypeScript 编译器（tsc）默认不修改模块路径中的文件扩展名，因此 import('./translations/${locale}.ts') 不会自动转为 .js；若需保留 .ts 后缀，必须配合支持路径重写的打包工具（如 Vite、Webpack）或启用 moduleResolution: "bundler" 等新特性。 typescript 编译器（tsc）默认不修改模块路径中的文件扩展名，因此 `import('./translations/${locale}.ts')` 不会自动转为 `.js`；若需保留 `.ts` 后缀，必须配合支持路径重写的打包工具（如 vite、webpack）或启用 `moduleresolution: "bundler"` 等新特性。 在现代 TypeScript 项目中，使用动态导入（Dynamic Import）实现按需加载本地化资源（如 import(./translations/${locale}.ts)）是一种常见模式。但开发者常遇到一个关键问题： 当路径中显式写入 .ts 扩展名时，tsc 编译后生成的代码仍保留 .ts，导致浏览器或 Node.js 运行时报错 Failed to load module script 。 根本原因在于： TypeScript 编译器从不修改模块说明符（module specifier）中的路径字符串 。即使源码是 .ts，输出的 ESM 代码中 import() 内部的字符串字面量也原样保留 —— 它不会、也不能将 ${locale}.ts 自动替换为 ${locale}.js。这是设计使然，也是与 ECMAScript 模块规范对齐的结果。 ✅ 正确做法：优先使用 .js 扩展名 对于纯 tsc 构建流程（无额外打包器），最简洁、兼容性最佳的方案是 在动态导入路径中直接使用 .js 扩展名 ： ⚠️ 注意事项： 确保对应 .ts 文件已通过 tsc 编译为同名 .js 文件（含类型声明 .d.ts）； ./translations/zh-CN.ts → 输出为 ./translations/zh-CN.js； TypeScript 会正常解析 .d.ts 类型，运行时加载 .js，零配置、零风险。 ⚙️ 进阶方案：启用 moduleResolution: "bundler" TypeScript 5.0+ 引入了 moduleResolution: "bundler" 模式，专为与 Vite、Webpack、esbuild 等现代打包工具协同工作而设计。它允许你在源码中保留 .ts 扩展名，并配合 allowImportingTsExtensions: true 解析 .ts 导入： TypeScript-45分钟入门课件源码 TypeScript-45分钟入门课件源码 下载 ✅ 此配置下，以下写法合法且可被 TypeScript 类型检查识别： ⚠️ 关键前提： tsc 仅负责类型检查和生成声明文件（.d.ts），不再生成 .js；实际路径重写（.ts → .js）、代码分割、HMR 等均由外部打包器完成 。例如： Vite ：开箱即用，自动解析 .ts 动态导入并映射到编译后产物； Webpack 5+ ：需确保 resolve.extensions 包含 '.ts'，且使用 ts-loader 或 swc-loader 配合 resolve.fullySpecified: true； 单独用 tsc？❌ 不可行 —— noEmit: true 下无 JS 输出，tsc 本身不执行任何路径转换。 ? 总结与建议 场景推荐方案是否需要打包器纯 tsc 构建（如库发布、CI 类型检查）使用 .js 扩展名 + 预编译❌ 否应用开发（React/Vue/Svelte 等）moduleResolution: "bundler" + .ts 路径✅ 是（Vite/Webpack）需要 Deno/Node.js ESM 原生运行显式写 .js，或使用 --loader ts-node/esm⚠️ 视环境而定 ? 最佳实践： 除非你明确依赖打包器的高级能力（如 code-splitting、tree-shaking、HMR），否则应坚持在动态导入中使用 .js 扩展名 。它符合 ESM 规范、规避所有路径歧义、无需额外配置，是 TypeScript 官方文档明确推荐的方式（ ESM Node Handbook ）。 最后提醒：永远不要在生产环境中直接运行 .ts 源码 —— 动态导入的目标必须是运行时可解析的真实文件（.js 或经打包器注入的虚拟模块）。清晰区分「类型检查阶段」与「运行时模块解析阶段」，是驾驭 TypeScript + ESM 的核心认知。