背景

大家出来写 Bug 代码的，难免会出 Bug。

文章背景就发生在一个 Bug 身上，

有一天，测试慌张中带着点兴奋冲过来：

测试："xxx系统前端线上出 Bug 了，点进xx页面一片空白啊"。

我："纳尼？我写的Bug怎么会出现代码呢？"。

虽然大脑一片空白，但是锅还是要背的。

进入页面一看，哦豁，完蛋，cannot read the property 'xx' of undefined。确实是前端常见的报错呀。

背锅王，我当定了？未必。

我眉头一皱，发现事情并不是那么简单，经过一番猛如虎的操作之后，最终定位到问题是：后端接口响应的 JSON 数据中，一个嵌套比较深的字段没有返回，即前端只读到了 undefined。

咱按章程办事，后端提供的接口文档指定了数据结构，那你没有返回正确数据结构，这就是你后端的锅，虽然严谨点前端也能捕获到错误进行处理，但归根到底，是你后端数据接口处理有问题，这锅，我不背。

甩锅又是一门扯皮的事情，杀敌一千自伤八百，锅已经扣下来了，想甩出去就难咯，。

唉，要是在接口出错的时候，能立刻知道接口数据出问题，先发制人，马上把锅甩出去那就好咯。

这就是本文即将要讲述的 "Typescript 运行时数据校验"。

为什么要运行时校验数据？

众所周知，Typescript 是 JavaScript 超集，可以给我们的项目代码提供静态类型检查，避免因为各种原因而未及时发现的代码错误，在编译时就能发现隐藏的代码隐患，从而提高代码质量。

但是，TypeScript 项目的一个常见问题是: 如何验证来自外部源的数据并将验证的数据与TypeScript类型联系起来。 即，如何避免后端 API 返回的数据与 Typescript 类型定义不一致导致的运行时错误。

Typescript 能用于运行时校验数据类型，那么有没有一种方法，能让我们在 运行时 也进行 Typescript 数据类型校验呢？

io-ts 解决方案？

业界开源了一个运行时校验的工具库：io-ts。

// io-ts 例子import * as t from 'io-ts'// ts 定义interface Category { name: string categories: Array}// 对应上述ts定义的 io-ts 实现const Category: t.Type = t.recursion('Category', () => t.type({ name: t.string, categories: t.array(Category) }))

但是，如上面的代码所示，这工具看起来就有点啰嗦有点难用，对代码的侵入性非常强，要全盘依据它的语法来重写代码。这对于一个团队来说，存在一定的迁移成本。

而我们更希望做到的理想方案是：

写好接口的数据结构 typescript 定义，不需要做太多的额外变动，直接就能校验后端接口响应的数据结构是否符合 typescript 接口定义

理想方案探索

首先，我们了解到，后端响应的数据接口一般为 JSON，那么，抛开 Typescript，如果要校验一个 JSON 的数据结构，我们可以怎么做到呢？

答案是JSON schema。

JSON schema

JSON schema 是一种描述 JSON 数据格式的模式。

例如 typescript 数据结构：

type TypeSex = 1 | 2 | 3interface UserInfo { name: string age?: number sex: TypeSex}

等价于以下的 json schema ：

{ "$id": "api