面试防线：完全动态下发动作字典时前端 TypeScript 类型推导的破解方案
面试官提问：
“HATEOAS 通过后端动态下发 _links 决定动作. 但这跟 TypeScript 强类型思维完全相悖：因为 client.follow(“approve”) 是动态字符串。怎么找回 TS 的类型推导？”
核心回答思路 (STAR法则)
-
业务痛点 (Situation)
当请求重构为链式的 follow(“string”) 后，完全变成依赖黑盒字符串，极其容易敲错字母导致运行时报错，前端彻底丢失了类型安全护航。 -
技术考量 (Task)
这是一种矛盾：运行时需要极度灵活，编译时需要绝对严谨. 解决之道必须在构建链条 (Build Chain) 上做文章。 -
架构决策 (Action)
- 前后端共享领域字典：基于 OpenAPI 或后端的 JSON Schema，在 CI 管道拉通. 每次后端发版前，自动提取资源实体可能暴露的超媒体动作字典 key。
- 泛型元编程与 AST 自动生成：前端编写脚本抓取 JSON 后，利用 ts-morph 工具动态生成前端项目的 d.ts 类型声明文件。
- 深度约束客户端入参：在核心 client.follow 方法上施加严苛的泛型约束：follow
(actionName: K). 当开发在 VSCode 敲下代码时，编辑器会精准提示合法动作。
- 业务价值 (Result)
完美调和了运行时 HATEOAS 的解耦与 TS 编译时的安全性. 开发人员既不用查接口文档，又有类型护航。