Cloudflare 推出 tsrs：TypeScript Rust 编译器的兼容性与迁移评估

面对新的 TypeScript 编译器实现，全栈团队最值得先做的工作，是确认自己的等待时间花在哪里。类型检查较慢，可能值得尝试替代工具；如果主要耗时来自测试、打包或依赖安装，更换编译器就未必能明显缩短交付周期。tsrs 的发布提供了新的评估对象，采用决策仍然需要回到真实代码库。

tsrs 发布了什么

Cloudflare 于 2026 年 10 月 20 日介绍了 TypeScript 的 Rust 移植项目 tsrs，目前提供实验版本。官方表示，在类型检查工作线程数相同时，早期测试相对 TypeScript 7.0 最高快 8 倍、内存约少 70%；这些属于特定测试结果。项目强调跟随上游语言行为，也承认目前存在诊断输出顺序等差异。来源：Cloudflare 官方公告。

以下为面向全栈项目的独立评估建议，未对 tsrs 进行实际性能测试，也不代表官方兼容性承诺。

先定义要改善的开发体验

把类型检查从整条流水线中分离

建议先记录当前流水线中安装依赖、生成代码、类型检查、测试、构建各自的耗时。类型检查耗时十分钟和耗时十秒，适合投入的评估成本显然不同。同样，单个检查任务变快后，如果另一项任务仍决定流水线结束时间，团队看到的总收益可能有限。

对本地开发也应区分场景。首次打开仓库后的等待、修改一个文件后的反馈、执行一次完整检查，是不同的问题。评估目标可以写成“降低完整检查的中位耗时”或“减少内存不足导致的失败”，而不应只写“升级到更快的工具”。

为实验设置可复现的边界

选取一个固定提交，保留依赖锁文件、配置文件与生成代码，记录操作系统、处理器、内存限制及运行时版本。基线工具与候选工具应读取同一批文件，尽量使用相同资源条件。凡是无法对齐的选项，都要单独列出，避免把少检查了文件误判为性能提升。

冷启动和重复运行可以分别统计，但要说明清理了什么缓存、保留了什么状态。建议进行多次运行并报告中位数、波动范围与失败次数，不把最快一次当成代表结果。峰值内存也要注明测量口径，尤其要分清主进程和整个进程组。

兼容性验证要覆盖成功与失败

建立项目自己的诊断样本

只跑一遍目前能够通过的主分支，容易漏掉错误检测上的差异。可以从历史缺陷中提取小型样本，例如接口字段变更、类型收窄、泛型约束与空值处理，并刻意保留预期会失败的用例。对每个样本记录预期结果，再比较退出码、诊断类别、文件位置和信息内容。

比较日志时，可先归一化路径分隔符、颜色控制符以及输出排序；同时保留原始日志供复查。归一化规则应足够克制，不能为了消除差异而抹掉错误编号、位置或关键文本。若结果不同，先缩小为最小复现，再判断是项目配置问题、工具差异还是测试脚本失误。

从全栈边界挑选代表项目

评估样本应尽量贴近团队真正维护的系统。前端项目可以覆盖组件类型与事件处理；服务端可以覆盖请求参数、返回结构和运行环境类型；共享包可以覆盖导出入口与跨包引用。仓库如果包含生成的客户端、声明文件或多套配置，也应将它们纳入清单。

这些是建议验证的场景，并不意味着 tsrs 已经支持或不支持某项功能。对于尚未验证的组合，明确写“待验证”更有价值。一个真实业务模块的完整结果，通常比大量没有配置说明的演示项目更能支持迁移判断。

把命令行评测与编辑器体验分开

命令行检查通过后，还应单独观察日常工作流。自动补全、跳转、重命名、错误定位以及保存后的反馈是否正常，需要在实际编辑器配置下测试；不能仅凭终端任务成功，就推断整套开发体验已经等价。

对于涉及声明文件或其他输出的流程，应进一步比较产物，并运行下游消费者测试。若本次只验证类型检查，就在报告中限定结论范围，暂不扩展到构建产物或发布流程。保持边界清晰，可以防止一个小范围实验被误读成全仓库迁移许可。

用旁路检查降低迁移成本

一个稳妥的试用方式，是保留原有检查作为合并门禁，让候选工具在独立任务中运行，只收集结果。实验期间不要同时大改类型配置或依赖版本，否则一旦出现差异，很难识别原因。每次更新候选版本，都应重跑代表性样本并保留版本信息。

评估报告至少回答四个问题：检查了哪些项目，发现哪些差异，资源消耗如何变化，恢复原流程需要什么操作。通过条件也应提前确定，例如没有未解释的诊断差异、关键工作流通过验证、资源收益达到团队自己的目标。具体阈值由项目需求决定，不宜照搬外部基准。

达到条件后，可以先选择一个边界明确的包试用，再逐步扩大范围。旧命令、配置与锁定版本应保留为可执行的回退路径。若候选工具出现不稳定、诊断缺失或难以定位的问题，暂停扩大范围，继续使用已经验证的流程即可。

评估维护成本与实际收益

性能收益之外，还应为维护工作留出预算。建议指定一位负责人记录版本更新、兼容性问题与回退决策，避免实验任务长期无人解释。若需要额外脚本适配日志、安装包或编辑器集成，把这些脚本也纳入版本管理，并计算后续维护负担。

成本比较可以从团队自己的数据出发：一次检查节省多少时间，每天执行多少次，是否真的减少机器占用或开发者等待。不要把检查加速比例直接套用到云账单，更不要把并行执行中重叠的时间全部算成节省。若收益很小而排查成本持续上升，继续观察也可以是合理结论。

最终应保存一份简短决策记录，写清适用仓库、验证版本、尚未覆盖的场景以及重新评估的触发条件。它能帮助后来接手的人理解当时为何采用或暂缓，也能避免下一次工具升级从零开始。对于长期维护的项目，这份记录往往比一次漂亮的跑分更耐用。

结语

tsrs 值得进入工具链观察清单。对全栈团队而言，更有用的下一步是建立可重复的比较方法：先定位瓶颈，再验证诊断与产物，最后衡量整条开发流程的收益。这样，无论最终采用哪一种实现，团队都能积累一套可复用的编译器升级依据，而不是随着性能数字反复切换工具。