GraphQL除列表查询外是否还需要额外提供单条目查询？

从数据返回结果的角度来看，你的判断完全正确：按ID过滤的列表查询确实可以拿到和单ID查询完全一致的数据，UI侧也可以自由选择需要返回的字段属性，但两种接口在实际生产环境的价值差异极大，行业普遍同时提供两种接口是经过长期验证的最佳实践，核心原因如下：

• 性能开销差距显著
  哪怕过滤条件只有ID，列表查询也需要走完整的列表处理逻辑：校验分页参数、处理排序规则、拼接所有预设的筛选条件、甚至要关联多表做权限过滤，最后才能定位到目标条目，部分列表接口的实现还会默认加分页条数限制，调用侧还要额外做「取返回数组第一个元素」的处理。而单ID查询是直接走数据库主键索引拿数据，跳过所有无关的列表处理逻辑，接口QPS能高出数倍，数据库压力也会小很多。
• 接口语义清晰，降低后续维护风险
  接口本身的路径就是最直观的文档：GET /resources/{id} 所有人一眼就能看懂是查询单个资源，返回的是对象结构；而GET /resources?id=xxx 是查询资源列表，返回的是数组结构。如果所有单条查询都用列表接口实现，后续迭代列表接口时很容易出现逻辑冲突：比如列表接口加了「仅展示当前用户创建的资源」的权限规则，但单条查询的规则是「只要有资源读权限就可以查看」，这时候就会出现单条查询用列表接口拿不到数据的问题；再比如列表接口为了降低返回数据量对敏感字段做了脱敏，但详情页需要展示完整字段，就需要额外加参数做特殊判断，长期下来代码会变得越来越冗余难维护。
• 异常处理更简单可靠
  单ID查询的异常判断逻辑非常符合直觉：ID不存在直接返回404，权限不足返回403，参数非法返回400。但用列表查询实现单条查询时，调用侧如果拿到空数组，还要额外判断是ID不存在、还是权限不足、还是列表接口本身报错，前后端的异常处理逻辑都会复杂很多，出bug的概率也会大幅上升。
• 适配通用生态组件的成本更低
  现在绝大多数缓存、鉴权、API网关、监控组件对REST风格的单资源接口都有默认适配规则：比如缓存可以直接用/resources/{id}作为key，自动实现缓存过期、更新失效；监控组件可以直接统计单个资源的访问频次、错误率。如果用列表接口传ID的方式实现单条查询，所有这些通用能力都要额外做定制开发，投入产出比极低。

行业通用的最佳实践：
除非你的业务场景对接口数量有极端苛刻的要求，否则都建议同时实现两种接口：

1. 列表查询仅用于多资源的筛选、排序、分页场景，不要承接单资源查询的流量
2. 单ID查询单独做逻辑实现，直接复用列表接口的字段序列化、基础权限判断逻辑即可，额外开发成本极低，但长期收益非常高

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