用途：审计前端对 API 响应的消费方式，找出前端类型假设与后端实际返回之间的不一致，属于主动排查而非运行时修复。
主要能力：包含四类检查。一是结构差异，找出前端假设存在但后端从未发送的字段，常见于嵌套对象对应后端外键（如 userId）而非已填充关联；二是可空性缺口，前端把字段标为 T 而后端可能返回 T | null，尤其在使用 as 断言时被静默忽略；三是可选链审计，区分 ?. 掩盖真实结构错误与字段本就可选，以及 ! 断言在 API 数据上导致的崩溃风险；四是序列化差异，检查 Date 经 JSON 变为字符串、Prisma select 未选字段、NestJS @Exclude() 剥离字段、中间件重命名等。
使用方式：先推断代码库中响应消费位置（fetch/axios、React Query、SWR、RTK Query、tRPC）、类型声明方式、后端是否可读、失败模式，再逐项执行四类检查。加固手段是在请求边界用 Zod 等做校验，例如 UserSchema.parse(await res.json())，或在 React Query 的 queryFn 中集中校验，也可用 safeParse 做非抛错校验并记录日志。
适用场景：前端与后端分离、类型手写或断言较多、存在静默错误数据的项目。
限制：资料未提供具体安装命令、收费、平台支持或效果数据；检查依赖可读取后端序列化器或数据库 schema，否则只能做前端侧推断。