这个系列的第一篇里，我主张在写任何代码之前先把OpenAPI契约定下来。这一篇要讲的，是让这份契约真正“回本”的工具：Orval。
手写前端的API层，是那种没人会承认自己喜欢的活儿。从后端文档里抄类型，第四十次写同一个请求封装，三周后有人把某个字段改了名，一半的调用就悄无声息地坏掉了。Orval直接把这个活儿删掉了。把它指向你的OpenAPI规范，客户端代码就自动生成：每个接口都有带类型的函数，模型和契约完全一致，还有后端根本不存在时就能用来开发的mock。
前端团队为什么喜欢它#
mock生成是最被低估的部分。规范一旦谈定，前端就能起一个假服务器，对着它把整个UI做完，不用再等那些永远“快好了”的接口。等真正的后端上线，把客户端指过去，大部分东西直接就能跑，因为两边是照着同一份文档做的。
另一个收获是：无聊的代码从此“天生正确”。没有人会在手写的请求体里敲错字段名了，因为根本没有人再手写请求体。
后端团队为什么也喜欢它#
规范成为唯一事实来源之后，日常沟通都变了。不再有“这个接口到底返回什么来着？”的群聊追问，前端直接看生成的类型就行。后端开发者被打断得更少，反馈来得更早：前端对着mock开发时觉得哪个API别扭，你在改起来还便宜的阶段就知道了，而不是等它进了生产环境。
怎么融入工作流#
没什么花哨的。后端提出规范，两个团队一起评审；前端用Orval生成客户端和mock，直接开工；后端按同一份契约实现真实接口。规范一变，两边重新生成，编译器会准确告诉你哪里坏了。最后这一点才是全部意义所在：前后端之间的偏差，从生产事故变成了编译错误。
这不是什么光鲜的工具。它只是安安静静地消灭了团队之间一整类争吵，这笔买卖我每次都愿意做。