Jiti 和 ts-node 对比：TypeScript 运行时怎么选
ts-node 是 TS 运行时的老牌标准，Jiti 以零配置与智能缓存后来居上。本文从 ESM 兼容、执行方式、测试集成、类型检查等维度全面对比。
日常开发跑 TS 选 Jiti（零配置、ESM/CJS 通吃、磁盘缓存快）；需要类型检查与执行一体化、深度 tsconfig 定制的场景 ts-node 仍有用武之地。但大方向上：新项目该评估的是"tsx 或 Jiti"，ts-node 已处于维护性更新状态。
基本盘
ts-node：TypeScript 官方编译器 API 的运行时封装，与 tsconfig 深度绑定，默认做类型检查，长期是"Node 跑 TS"的标准答案。
Jiti：UnJS 出品的现代加载器，零配置、双模块格式通吃、磁盘缓存，被 Nuxt/ESLint 等工具链广泛内嵌。
ESM 与模块兼容性
这是两者差距最大的战场：
- ts-node：ESM 支持长期磕磕绊绊，loader 模式配置繁琐，
"type": "module"项目里踩坑率高； - Jiti：ESM 与 CJS 同一入口通吃，import ESM-only 包、require TS 文件都自然工作。
2026 年的 npm 生态 ESM-only 包越来越多，这一项几乎一票否决。
执行方式与性能
- ts-node：
ts-node script.ts或node --loader ts-node/esm；类型检查拖慢启动（可用--transpileOnly跳过提速，但等于放弃它的核心特性）； - Jiti：
jiti script.ts或可编程 API；转译结果写磁盘缓存，二次启动毫秒级。
两者开发体验都能用，Jiti 的缓存机制在"频繁重启"场景（脚本工具、配置加载）优势明显。
REPL 与测试集成
- ts-node 提供交互式 REPL（
ts-node直接进），Jiti 无内置 REPL； - 测试框架：Jest 时代 ts-node 生态成熟；Vitest 时代两者都不需要（Vitest 自带 TS）。
ts-node + mocha的组合仍是存量项目的常见配方。
类型检查哲学
- ts-node：默认每次执行都做完整类型检查——类型错误当场拒绝运行；
- Jiti：纯转译，类型检查交给编辑器与 CI。
现代共识偏向后者：类型检查是静态分析环节的事，运行时不该为此买单。
决策建议
| 场景 | 选择 |
|---|---|
| 存量 ts-node 项目，运行正常 | 不动 |
| 新项目需要跑 TS | tsx 或 Jiti |
| 需要加载用户 TS 文件的工具链 | Jiti |
| 强依赖执行时类型检查的工作流 | ts-node --transpileOnly 之外的模式 |
常见问题（FAQ）
Q：ts-node 是死了吗？
没有死，但活跃度与推荐度明显下降——Node 生态的表演舞台转到了 tsx、Jiti 与 Node 原生 TS 支持。存量项目无需恐慌性迁移，新项目不建议再选。
Q：Jiti 能读 tsconfig 的路径别名吗？
通过配置选项手动映射 alias（不与 tsconfig 自动同步）；tsx 则自动读取 tsconfig paths——高频用别名的项目这点 tsx 更省心。
Q：从 ts-node 迁移到 Jiti 的成本？
极小：把启动命令从 ts-node 换成 jiti，删除 ts-node 相关配置即可。类型检查环节如果之前依赖 ts-node 的，补上独立的 tsc --noEmit 步骤。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
