GraphQL查询场景：返回Null与抛出错误的技术抉择疑问

这绝对是GraphQL开发里绕不开的一个抉择点，我当初刚上手的时候也纠结了好久。两种方案没有绝对的对错，核心得看你的业务场景和你想传递给客户端的语义是什么。

先把两种实现再明确下：

方案一：返回Null（可空类型） #

type Person { firstName: String! lastName: String! }
type Query { getPerson(firstName: String!): Person }

这种方式的核心是把“查询不到用户”当成正常的业务结果来处理。

• 好处是客户端处理起来很顺畅：前端只需要判断data.getPerson是否为null，就能直接展示“未找到该用户”的提示，不用额外写错误捕获的逻辑。
• 适合的场景：比如用户在搜索框输入一个任意名字查询，找不到匹配的结果是完全符合预期的，这时候返回null就很合理。

方案二：抛出错误（非空类型） #

type Person { firstName: String! lastName: String! }
type Query { getPerson(firstName: String!): Person! }

这种方式传递的语义是：这个查询理应返回一个有效结果，如果没找到，那就是异常情况。

• 好处是能明确区分“正常无结果”和“系统/数据异常”：比如你根据已登录用户的ID去查询个人信息，理论上这个用户肯定存在，如果查不到，那大概率是数据丢了或者查询逻辑出问题了，抛出错误能让客户端立刻感知到这不是正常情况。
• 注意点：抛出错误的时候一定要带上清晰的错误信息，比如"message": "Person with firstName 'Alice' not found"，别只抛个模糊的错误，不然客户端根本不知道问题出在哪。
• 适合的场景：当查询的对象是“必须存在”的（比如通过主键查询已存在的资源），这时候用非空类型+抛错误更合适。

总结建议 #

• 如果“查不到数据”是业务流程中允许的、预期内的情况 → 选可空类型返回null
• 如果“查不到数据”意味着系统出问题了，属于异常场景 → 选非空类型并抛出明确的错误
• 另外也要考虑客户端的开发成本：返回null需要前端做空值判断，抛错误需要前端处理错误捕获，根据你的团队习惯和业务优先级来平衡就行。

内容的提问来源于stack exchange，提问作者Eyal