展开说一下 GraphQL 的问题吧 GraphQL 核心的优势并不是所谓的类型系统，实际上强类型约束的在 RESTful 体系下也能很好的实现。充分利用了 Zod 能生成多端代码的 orpc 方案，Python 生态中的 FastAPI + Pydantic 方案都能实现类似的效果 GraphQL 最核心的优势是在于数据放题，即客户端可以根据自己的需求灵活的请求数据。这也是传统 BFF 层实现的主要功能之一。 但是和传统 BFF 层不一样的地方在于，现在 GraphQL 的实现通常会和业务进行强绑定，没有抽离出单独的基建来处理类似的问题。 而在这种情况，灵活性将会带来非常多的问题，在 GraphQL 体系下（或者说类似的 BFF 方案下沉到业务后都会面临的问题）。 最简单的一点，灵活性将带来更大的攻击面。最简单的一点，恶意用户可以构造出足够复杂的 Query 来通过单纯的 AST 解析来大量消耗你的服务器资源。 当然很多人可能会说，啊，你限制 Query 的复杂度不就好了？那我问你，计算 Query 的复杂度是不是需要也还是需要解 AST ？ 当然还有人可能会说，那你限制 Query 的 Pattern 不就好了？那我问你，你的 Pattern 是不是也需要解 AST ？而且你把 GraphQL 最大的优势给限死了，你和传统的 RESTful API 有什么区别？ 而且 GraphQL 的 AST 解析这一点如果不从业务解出来，配合 Node 这种单线程模型，你 Event loop lag 直接被拉炸，用户体验上升了N个台阶 GraphQL 本身要做的很多东西都需要单独的基建来和业务解开，比如 Query 级别的 Rate Limit， 特殊的鉴权逻辑等等 坦白说，对于数据平台或者内部服务，GraphQL 可能是个还不错的选择。但是对于上了量的 toC 业务来说，GraphQL 会比传统的 RESTful API 带来更多的复杂度和不确定性，会格外的吃基建的开发。