TSX 和 Node 原生 TypeScript 支持对比
Node 23.6 稳定了原生 TS 支持后，TSX 还值得用吗？本文从功能覆盖、开发体验、配置复杂度全面对比官方与社区方案。
简单脚本与零依赖场景用 Node 原生（node app.ts）；需要 watch 模式、路径别名、REPL 等开发体验选 TSX。两者不是替代关系——原生方案在吃掉 TSX 的基础场景，TSX 的价值在开发体验层。
两个方案
Node 原生：Node 22.6 实验、23.6 稳定的类型剥离——运行时直接擦除类型执行，零依赖官方支持。
TSX：esbuild 驱动的社区方案——执行之外的开发体验全家桶。
功能对比
| 能力 | Node 原生 | TSX |
|---|---|---|
| 类型剥离执行 | ✓ | ✓ |
| watch 模式 | node --watch（有） | tsx watch（更成熟） |
| tsconfig paths | ✗ | ✓ |
| REPL | ✗ | ✓ |
| ESM/CJS 互操作 | 按 Node 规则 | 更宽容 |
| 装饰器等特殊语法 | 受限（需 flag） | esbuild 规则 |
| 依赖 | 零 | 需安装 |
开发体验差异
- watch：node --watch 可用；tsx watch 的重启速度与输出体验打磨更细；
- 错误堆栈：TSX 的 sourcemap 映射天然精确；原生方案的堆栈映射在持续完善；
- 配置：原生零配置但"能力按 Node 规则"；TSX 吃 tsconfig 的习惯更贴近 TS 开发者预期。
生产与 CI 的考量
CI 脚本用原生方案零依赖（镜像小、无安装）；本地开发用 TSX 体验好。两者共存完全合理——都执行同一份 TS 代码。
常见问题（FAQ）
Q：原生支持会让 TSX 消失吗？
基础场景在被替代，开发体验层（watch/REPL/paths）仍有空间。类似 node --test 与 Vitest 的关系——官方底线抬升，社区工具上移。
Q：类型检查怎么办？
两者都不做——tsc --noEmit 是通用答案（编辑器 + CI）。
Q：迁移路径？
TSX → 原生：确认不依赖 paths/装饰器后，启动命令直接替换。成本几乎为零。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
