TypeScript 的魔法技能：satisfies
现在，随着 TS 4.9 的发布，在 TypeScript 中有了一种新的、更好的方式来做类型安全校验。它就是 satisfies ：
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes = {
AUTH: {
path: "/auth",
},
} satisfies Routes; 为什么是 satisfies
在上面的示例中，我给出了 satisfies 的使用示例，但是我并没有解释那样做的原因。现在，是该给你解释解释了。
让我们从使用 TS 的标准类型声明重写上面的示例来进行一个对比：
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes: Routes = {
AUTH: {
path: "/auth",
},
}这看起来似乎没有什么呀，很正常，IDE 也会自动帮我们进行自动补齐。
但是，当我们使用 routes 对象时，因为 IDE 并不知道实际配置的路由是什么。
例如，下面这行代码编译得很好，但会在运行时会抛出错误:
routes.NONSENSE.path // TypeScript 报错：发现这个路由属性不存在为什么会这样? 这是因为我们的 Routes 类型可以接受任何字符串作为键。所以TypeScript 批准任何键访问，包括从简单的错别字到完全没有意义的键。
有同学会说：“那么用 as 关键字来解决不行吗” 。
很好的问题，我们接着看下面这段代码，用 as 会起到什么效果：
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes = {
AUTH: {
path: "/auth",
},
} as Routes这是 TS 中常见的做法，但实际上是相当危险的。
因为我们不仅会遇到和上面一样的问题，而且你会写出完全不存在的键值对，因为 TypeScript 会以另一种方式看待这样的写法：
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes = {
AUTH: {
path: "/auth",
nonsense: true,// TS 可以编译，但这不是一个有效的属性
},
} as Routes一般来说，你应该尽量避免在 TypeScript 中使用 as 关键字。
Satisfies
现在，我们再使用 satisfies 关键字重写上面的例子看看：
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes = {
AUTH: {
path: "/auth",
},
} satisfies Routes有了这个，我们会得到了我们想要的所有正确的类型检查:
routes.AUTH.path // ?
routes.AUTH.children // ? routes.auth has no property `children`
routes.NONSENSE.path // ? routes.NONSENSE doesn't exist同时，在 IDE 中还能进行自动补全功能:
我们再举一个稍微复杂一点的例子，进一步理解:
type Route = { path: string; children?: Routes }
type Routes = Record<string, Route>
const routes = {
AUTH: {
path: "/auth",
children: {
LOGIN: {
path: '/login'
}
}
},
HOME: {
path: '/'
}
} satisfies Routes我们从下图中看到，IDE 自还是能够帮助你进行自动补全和类型检查，一直精确到你的 routes 的叶子属性:
routes.AUTH.path // ?
routes.AUTH.children.LOGIN.path // ?
routes.HOME.children.LOGIN.path // ? routes.HOME has no property `children`与 as const 结合
当然，在开发中你还可能遇到的一种情况是，仅使用简单的 satisfies 关键字，我们对对象的捕获比理想的情况要松散一些。
例如，下面的代码中，
const routes = {
HOME: { path: '/' }
} satisfies Routes如果我们检查 path 属性的类型，我们会得到字符串类型:
routes.HOME.path // Type: string但是当涉及到配置时， const 断言(又名 as const)真正发光的作用便来了。我们在这里使用 as const，我们会得到更精确的类型，精确到字符串的字面量 '/':
const routes = {
HOME: { path: '/' }
} as const
routes.HOME.path // Type: '/'那这么做的理由是什么吗？我平时很少遇到这样的情况。
那我想所得是，假设你有一个这样的方法，它一直是类型安全的，它接受的确切 path:
function navigate(path: '/' | '/auth') { ... }如果我们只使用 satisfies，其中每个 path 只知道是一个 string，那么 TS 会在报类型错误:
const routes = {
HOME: { path: '/' }
} satisfies Routes
navigate(routes.HOME.path)
// ? Argument of type 'string' is not assignable to parameter of type '"/" | "/auth"'因为 Home.path 是一个有效的字符串 ('/')，但是 TypeScript 说它不是。
那么，这种情况下，我们可以通过组合 satisfies 和 as const 得到最好的结果：
const routes = {
HOME: { path: '/' }
- } satisfies Routes
+ } as const satisfies Routes现在，我们有了一个很好的解决方案，通过类型检查一直到我们使用的确切的字面量值。
const routes = {
HOME: { path: '/' }
} as const satisfies Routes
navigate(routes.HOME.path) // ? - as desired
navigate('/invalid-path') // ? - as desired最后，你可能会问，为什么不直接使用 as const 呢?
对于 as const，在创建对象时，我们不会对对象本身进行任何类型检查。因此，这意味着在我们的 IDE 中没有自动检查，也没有在编写时对错别字和其他问题的警告。
这就是为什么要进行组合的原因。
Typescript 4.9 引入了新的 satisfies 关键字，它对于 Typescript 中大多数与类型检查、匹配相关的任务都非常方便。
与标准类型声明相比，它可以在类型检查和理解匹配的细节之间取得优雅的平衡，以获得最佳类型安全性。还没用上的同学，还去试试吧~