TSX 和 ts-node 对比：TypeScript 运行时的时代更替
ts-node 曾是标准，TSX 凭 esbuild 速度改写了规则。本文从架构、类型检查、ESM 支持、watch 模式与测试集成全面对比。
TSX 全面胜出：启动快一个数量级、ESM 零配置、watch 体验成熟、REPL 内置。ts-node 仅剩"执行时类型检查"这一差异化，而现代工作流已把类型检查移到编辑器与 CI。新项目选 TSX，存量 ts-node 项目建议排期迁移。
架构差异
- ts-node：调用官方 TypeScript 编译器——完整类型检查，启动与运行开销大；
- TSX：esbuild 转译——不检查类型，毫秒级启动。
架构差异决定一切：ts-node 用编译器跑代码，TSX 用转译器跑代码。
类型检查哲学
ts-node 的"运行时类型检查"在当年是卖点；现代共识：类型检查是静态环节（编辑器 + CI），运行时不该为此付出启动成本。TSX 代表了这个范式转移。
ESM 支持
ts-node 的 ESM 模式（--loader）配置繁琐、坑多；TSX 对 ESM/CJS 的处理开箱即用。2026 年的生态 ESM 已成主流——这一项体验差距决定性。
Watch 与 REPL
- ts-node 需配 nodemon 等外部工具；
- TSX 内置
tsx watch（增量快）与 REPL——开发循环的完整性差距。
测试集成
ts-node 时代的 mocha/jest 集成是其存量价值；Vitest 时代测试框架自带 TS 转换——ts-node 的这个阵地也已易手。
迁移要点
- 启动命令替换：
ts-node→tsx； - 确认 CI 有独立类型检查（
tsc --noEmit）； - 删除 ts-node 配置段；
- 装饰器项目（NestJS/TypeORM）先验证 esbuild 兼容性。
常见问题（FAQ）
Q：ts-node 有安全风险吗？
没有——它只是停在了过去。继续使用没有急迫风险，但新能力（Node 新版特性适配）会优先在社区活跃工具上落地。
Q：TSX 的类型错误怎么发现？
编辑器实时红浪 + pre-commit 跑 tsc --noEmit + CI 门禁——三重保障比"运行时才发现"更早。
Q：Jest 项目从 ts-node 迁走？
Jest 的 TS 支持建议走 @swc/jest 或 babel 路径；新项目测试框架直接 Vitest（TS 原生、更快）。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
