# 为什么这么快：TS7 原生编译器

先回答一个更容易被忽略的问题：**ts-grm 为什么那么依赖编译器性能？**

## 类型体操是特性，也是成本

ts-grm 的设计核心是「零代码生成」：不跑任何预处理器，模型、视图、查询链、结果形状全部由 TypeScript 的类型系统在编译期推导。这套类型系统非常**重**——为了做到

- `model(...)` 只写一次元数据，字段类型与可空性从 class 定义推断；
- `dto.view(...)` 让查询结果的 DTO 形状精确到列；
- 查询链 `q.where(...).orderBy(...).select(...)` 在**编译期**校验列存在、类型匹配、取形闭合；
- 关联、多态、组合键等高级取形都有对应的类型级约束；

框架内部铺了大量条件类型、泛型约束与重载。后果是：同样的「业务代码量」，ts-grm 的类型检查负担比普通 ORM 重得多——**在老的 JS 编译器上，这类体操会明显拖慢检查；换到 TS7 原生编译器后，同一份代码通常更快。快多少取决于代码与机器，别信拍脑袋的倍数，直接看下方实测。**

这正是 ts-grm 上游 `package.json` 把 TypeScript 直接钉在 `^7.0.2` 的原因。

## TypeScript 7 换了一台发动机

TypeScript 7 不再是「JS 写的编译器 + 自举」——核心编译管线用原生语言重写，`tsc` 与语言服务（tsserver）都是原生二进制。对类型体操密集的代码，收益主要体现在两处：

- **类型计算更快**（条件类型展开、泛型实例化不再经过 JS 解释）；
- **冷启动更快**（不再需要加载整套 JS 编译器再暖机）。

具体能快到什么程度，与本机、与代码形态都相关——不做任何口头承诺。

## 类型检查实测

下面是同一份 ts-grm 类型样例（**本项目全部实体类**：书库 / 会员 / 任务 / 订单域共 12 个实体，附 6 组真实查询——覆盖继承（两种）、多态取形、embedded 复合主键、m2o/m2m、公式与软删除，代码量中等偏少）分别交给 TS7 原生编译器与 TS 5.9（JS）跑 `tsc --noEmit` 的真实耗时。点击按钮即可复测——数据不是截图，是刚跑的。

<Ts7Bench />

## 这对你意味着什么

1. **IDE 体验有望明显改善**：VS Code 内置 TS7 语言服务后，ts-grm 的补全、悬停与错误提示通常会更跟手（量级因机器而异）。Monaco 等网页编辑器会随生态跟进。
2. **CI 成本有望下降**：类型检查整体耗时缩短后，提交前跑一遍 `tsc --noEmit` 会更容易成为习惯。
3. **框架可以更「贪心」**：编译器足够快，ts-grm 才敢把更多约束塞进类型系统——类型体操不是炫技，是运行时零成本的校验。性能天花板由编译器托底。

## 想继续深入？

- 感受类型推导密度：回到[快速上手：查询](../getting-started/query)页，在工作区把示例改复杂些，注意每个中间变量的悬停类型；
- 阅读框架中类型最重的地方：`dto.view` 与查询链的声明；
- 与「上一代」对照：尝试把任意示例页代码复制到本地用 `tsc 5.x` 检查，再换 `tsc 7`——差值就是这一页要讲的事。