Jiti 和 TSX 对比：现代 TypeScript 运行时双雄
Jiti 靠零配置与磁盘缓存见长，TSX 以 esbuild 的速度与开发体验取胜。本文从性能、模块处理、测试集成、类型支持等维度深度对比两大现代 TS 运行时。
开发期跑应用选 TSX（esbuild 驱动、watch 模式优秀、自动读 tsconfig 别名）；构建工具链/CLI 需要加载用户 TS 文件选 Jiti（可编程 API、磁盘缓存、模块格式通吃）。两者都比 ts-node 更现代，可以按场景共存于同一项目。
基本盘
TSX：esbuild 驱动的 TS 执行器，主打极速与开发体验（watch、REPL），是"ts-node 继任者"竞赛的领跑者。
Jiti：UnJS 的可嵌入式加载器，主打零配置、双模块兼容与磁盘缓存，统治着"工具加载用户 TS 配置"这个细分场景。
性能对比
- TSX：esbuild 转译内存驻留，冷启动与运行都极快；watch 模式增量重建几乎无感；
- Jiti：首次转译后写磁盘缓存，后续启动更快（连转译都省了）；长驻进程场景两者无差异。
"快"对两者都不是问题——选择看别的维度。
REPL 与命令体验
TSX 提供完整 REPL（tsx 直接进入交互式）与 watch 模式（tsx watch app.ts），命令体验对标 node 本身——node app.js 换成 tsx app.ts 仅此而已。Jiti 的 CLI 更朴素，主战场是可编程 API。
模块系统与 Node 兼容
- Jiti：ESM/CJS 互操作是其招牌——CJS 项目里 import ESM-only 包、混用模块格式，Jiti 兜底；
- TSX：遵循 Node 的模块语义（package.json 的 type 决定行为），与现代 Node ESM 生态对齐更"正统"，但混合格式的老项目需要按 Node 规则整理。
测试与类型工作流
两者都不做类型检查，测试都推荐 Vitest（原生 TS）。类型把关同样是编辑器 + tsc --noEmit。差异：TSX 自动读取 tsconfig 的 paths 别名；Jiti 需在选项中手动声明 alias。
TypeScript 特性兼容
esbuild（TSX 底层）不支持少数需要类型信息的特性：装饰器元数据（emitDecoratorMetadata）——NestJS/TypeORM 重度依赖，用 TSX 跑这类项目要验证；Jiti 用 Babel 系转译，部分边角特性行为不同。遇到"装饰器不灵"先怀疑这条。
决策速查
| 需求 | 选谁 |
|---|---|
| 日常开发跑服务/脚本 | TSX |
| watch 模式开发循环 | TSX |
| CLI 工具要加载用户 TS 配置 | Jiti |
| CJS 老项目消费 ESM-only 包 | Jiti |
| NestJS/TypeORM（装饰器元数据） | 验证后谨慎选 |
常见问题（FAQ）
Q：能在同一个项目里两个都用吗？
完全合理：开发用 tsx watch，CLI 脚手架内部用 Jiti 加载配置——它们不冲突，各司其职。
Q：Node 24 原生跑 TS 了，还需要它们吗？
原生类型剥离在成熟中，但 watch 体验、缓存、别名、模块互操作这些仍是 TSX/Jiti 的价值。短期两者仍是主流开发体验。
Q：生产环境用哪个跑？
都不建议——生产用预编译产物（SWC/tsc 编译成 JS）。运行时方案是开发期工具。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
