Rslint 实测评估：基于 TypeScript 原生编译器的 ESLint 兼容 linter

它解决什么问题

传统 ESLint 在大型 TypeScript 项目上性能瓶颈明显，尤其是开启类型感知规则后，每次 lint 都要重复解析和类型检查。Rslint 的目标是用 TypeScript 原生编译器（typescript-go）替代 ESLint 的解析和类型系统，从而获得 20 到 40 倍的性能提升。它面向的是维护大规模代码库、且受够了 lint 等待时间的开发团队。README 强调其是 tsgolint 的 fork，而 tsgolint 已停止开发，因此 Rslint 填补了这一空白。它属于 Rstack 工具链的一部分，与 Rspack、Rsbuild 等工具并列，说明其定位是前端工具链中的一环，而非孤立项目。

架构与核心机制

Rslint 用 Go 编写，但底层依赖 TypeScript 7 的原生编译器（typescript-go）。这不是简单的解析器替换。它使用 TypeScript Compiler 的语义作为唯一事实来源，这意味着类型信息在 lint 过程中直接可用，不需要像 typescript-eslint 那样额外调用 TypeScript 编译器。README 提到它默认执行跨模块分析，而不是传统的文件级分析。这允许规则访问全局 checker 数据，实现更复杂的语义检查。架构上，它暴露 AST、类型信息和全局 checker 数据，供自定义规则使用。这种设计类似 Rust Clippy 的编译器集成方式，但针对 TypeScript。关键区别在于，ESLint 的规则是纯函数式的 AST 遍历，而 Rslint 的规则可以依赖类型上下文，这能消除许多类型边界 bug，但也意味着规则编写模型不同。

安装与配置

Rslint 以 npm 包 @rslint/core 分发，但核心是 Go 二进制。安装命令在 README 中未给出具体步骤，只指向 rslint.rs/guide。不过根据仓库布局，你大概率通过 npm 安装，然后使用 CLI 或配置文件。配置设计受 typescript-eslint 影响，因此迁移时可以将现有 ESLint 配置直接复制或稍作修改。README 宣称“最小配置”，类型化 lint 默认启用，无需额外设置 parser 或 type-aware 选项。这是与 ESLint 最大的不同：ESLint 需要手动配置 parserOptions.project 才能启用类型规则，而 Rslint 默认就做。若你从 ESLint 迁移，需要检查现有 .eslintrc 中的 parser 和 plugin 是否被支持，因为兼容是“尽力而为”，不是百分百。

兼容性的边界

README 明确说“Best Effort ESLint Compatible”，这意味着并非所有 ESLint 配置都能直接工作。它内置了所有 TypeScript-ESLint 规则和广泛使用的 ESLint 规则，但自定义插件（如 eslint-plugin-react、eslint-plugin-vue）不在承诺范围内。这些插件依赖 ESLint 的规则 API 和特定的 AST 节点，Rslint 虽然暴露了 AST，但未必兼容插件内部对 ESLint 环境的假设。另一个边界是规则的自定义方式：Rslint 允许你写自定义规则，但需要学习其暴露的 API，而不是直接复用 ESLint 的 rule 模块。对于重度依赖第三方规则库的团队，迁移成本可能高于预期。而且，如果某个规则在 Rslint 中行为不一致，你无法像 ESLint 那样简单禁用或替换，因为内置规则集是固定的。

性能声称与验证

README 声称 20 到 40 倍的速度提升，但这没有提供基准方法或具体数据。作为对比，typescript-eslint 的 tsgolint 项目本身就是一个性能实验，Rslint 继承了这个方向。性能提升主要来自两个来源：一是用 Go 编写的解析器和语义分析器，二是避免了 ESLint 中重复的类型检查。但实际提升取决于项目规模、规则数量和机器配置。对于小型项目，启动 Go 二进制的开销可能抵消部分收益。我无法验证这些数字，因为仓库没有附带 benchmark 脚本。如果你关心性能，应该在自己的代码库上运行 Rslint 并对比 ESLint 的时间，而不是依赖宣传数字。注意，README 中的 codspeed 徽标指向性能跟踪，但具体结果未展示。

维护与升级成本

Rslint 目前处于实验阶段，但活跃开发，最近一次提交是 2026 年 8 月，版本号 0.8.x。这意味着 API 可能随时变化，升级时可能需要修改配置或规则。它 fork 自 tsgolint，而 tsgolint 已停止开发，因此 Rslint 需要独立维护 TypeScript 编译器版本的支持。依赖 typescript-go 意味着 TypeScript 新版本发布后，Rslint 需要跟进更新，否则可能出现语法解析不兼容。许可证是 MIT，这对商业项目友好，没有 copyleft 义务。但注意，它属于 ByteDance 开源代码规范，贡献者需要遵守其行为准则，这本身不影响使用者。如果你计划长期使用，需要关注其版本发布节奏和 TypeScript 版本兼容性声明，这些在 README 中没有明确说明。

替代方案对比

最直接的替代是 typescript-eslint，它是 ESLint 的官方 TypeScript 插件，稳定且生态成熟。它采用文件级分析，类型信息通过额外调用 TypeScript 编译器获得，因此性能较慢，但兼容所有 ESLint 规则和插件。另一个替代是 Biome，一个用 Rust 写的 linter，同样追求性能，但它是独立的 lint 工具，不兼容 ESLint 配置。Rslint 的差异化在于它试图兼容 ESLint 配置，同时用编译器级分析提升性能。如果你不想放弃 ESLint 生态，Rslint 是唯一宣称能提供这种兼容性的高性能选项。但 typescript-eslint 的 tsgolint 项目已经停止，说明这条路有技术挑战。对于需要 React 或 Vue 规则的项目，Biome 或 typescript-eslint 可能更实际，因为 Rslint 的内置规则集不包含框架特定规则。

编辑结论

Rslint 适合那些受困于 ESLint 性能、且愿意接受实验性工具的大型 TypeScript 项目，尤其是 monorepo 场景。它不适合对稳定性要求极高、或依赖大量自定义 ESLint 插件（如 React、Vue 专属规则）的团队。在采用前，应先验证你的 ESLint 配置能否被其兼容层完整解析，特别是自定义 rule 和 parser 选项。同时要确认其内置规则集覆盖你的核心检查项，因为 README 只承诺兼容大多数配置，并未列出具体缺失规则。若你无法接受 Go 二进制带来的调试复杂度，或需要 lint 与编辑器、CI 深度集成，建议先等待其稳定版本或继续使用 typescript-eslint。最终判断：Rslint 的架构方向正确，但当前实验阶段意味着你必须在性能收益和生态成熟度之间做明确取舍。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes