Jiti 入门：零配置的 TypeScript 运行时加载器
Jiti 是 UnJS 团队的 TS 运行时加载器：无需编译直接运行 TS 文件，智能缓存、ESM/CJS 通吃，驱动着 Nuxt、Tailwind 等知名项目。本文讲解用法与配置。
Jiti 让你用 jiti index.ts 或一行 require('jiti')(__filename) 直接运行 TypeScript，零配置同时兼容 ESM 与 CommonJS。它的差异化优势是"嵌入式加载器"定位：作为库被工具链（Nuxt、ESLint 等）集成来加载用户的 TS 配置文件，这是它与 tsx/ts-node 最不同的战场。
Jiti 是什么
月下载 6000 万+，Nuxt、Docusaurus、Tailwind CSS、ESLint 都依赖它——这些工具需要加载用户写的 TypeScript 配置文件（nuxt.config.ts 之类），Jiti 就是幕后功臣。它的设计目标：作为一个可嵌入的加载器，让任何 Node 项目不经编译直接消费 TS。
两种使用方式
npm install jiti
# CLI 方式
npx jiti ./src/index.ts
// 库方式：在你自己的 CLI 工具里加载用户的 TS 配置
const { createJiti } = require('jiti');
const jiti = createJiti(__filename);
const config = jiti('./myapp.config.ts'); // 直接拿到 TS 模块的导出
模块解析的魔法
Jiti 对 ESM/CJS 的处理是"通吃"：import TS 文件、require ESM-only 的包、加载 JSON——同一个入口，自动处理模块格式差异。这正是工具链爱它的原因：用户配置文件用什么模块格式都行，加载方不用操心。
配置选项
const jiti = createJiti(__filename, {
cache: true, // 磁盘缓存（默认开，二次加载飞快）
requireCache: false, // 不走 Node require 缓存，便于配置热重载
interopDefault: true, // 自动解包 ESM default 导出
alias: { '@': './src' }, // 路径别名，对齐 tsconfig paths
});
缓存是 Jiti 性能的核心：首次转译后写入磁盘缓存，后续加载直接读——这也是它作为配置文件加载器几乎零开销的原因。
与 tsx/ts-node 的定位差异
- tsx/ts-node：面向"开发期跑应用"，强调 watch、REPL、调试器体验；
- Jiti：面向"在运行时加载 TS 模块"，强调可嵌入、零配置、缓存效率。
写应用脚本用 tsx 更顺手；写需要加载用户 TS 文件的工具（脚手架、CLI、框架）用 Jiti 更专业。
常见问题（FAQ）
Q：Jiti 做类型检查吗？
不做（Babel 式类型剥离）。类型正确性由编辑器与 CI 的 tsc --noEmit 保证。
Q：生产环境能用 Jiti 跑整个应用吗？
技术上可以，但定位不建议：生产用预编译产物（SWC/tsc 编译后跑纯 JS）。Jiti 的主场是开发期与工具链内嵌。
Q：Jiti 和 Node 22+ 的原生 TypeScript 支持冲突吗？
Node 原生 TS 支持（类型剥离）在快速演进，Jiti 团队也在适配。Jiti 的差异化仍在：ESM/CJS 互操作、缓存、别名、可编程 API——原生支持不解决这些。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
