说到GraphQL，现在技术圈几乎把它捧成了API界的救世主。两年前我们团队做某个数据聚合平台，技术选型时大家一致同意上GraphQL，理由无非是客户端灵活性、减少多次请求。当时我也跟着兴奋，觉得终于不用再被REST的多个端点折磨了。但如今项目跑了两年半，我越来越怀疑当初的决定是不是一个集体性的自嗨。
最先让我感到不对劲的，是调试体验。REST接口用浏览器或者Postman直接就能点开看，GraphQL呢？你得先学习查询语法，然后还得记住服务端暴露了哪些字段。刚开始大家还认真看Schema，到后来前端同事直接问我：这个字段能不能加上？我一脸问号，明明在文档里。更崩溃的是，某一处查询少传了参数，返回的错误信息含糊得像在打哑谜，定位问题全靠猜。相比之下，REST的404一眼就知道是路径错了。
再说性能，这是我最想吐槽的。GraphQL号称能精确获取数据，但代价是服务端要处理那些嵌套的解析器。我记得有一次，一个简单的文章列表接口，前端要同时拿作者信息和评论数，结果SQL执行了整整几十次——典型的N+1问题。我们不得不引入DataLoader，还得手动管理批量加载的缓存。REST的话，你可以在一个接口里直接join完成，或者干脆做个专门的聚合接口，逻辑清晰，性能可控。GraphQL把压力从客户端转移到了服务端，但很多团队根本没有应对这种流量的能力。
当然，我并不是要全盘否定GraphQL，它在某些场景下确实有优势，比如客户端类型多样、需要高度定制数据，或者像BFF层那样做聚合。但你有没有发现？现实中绝大多数项目，不过是几个固定的页面，数据需求变化不频繁。为了一点点灵活性，付出Schema管理、缓存策略、权限控制、学习成本这么多代价，真的值得吗？我觉得，很多人选择GraphQL并不是因为需要，而是因为它在简历上好看，或者想赶时髦。技术选型最怕的就是把工具当信仰，REST不高级，GraphQL也不低级，适用才是王道。
再说了，GraphQL社区的更新频率快得吓人，今天一个版本，明天一个最佳实践，文档还老是改。我这种记性不好的中年程序员，每次升级都要踩几个坑。有一次为了修一个深层嵌套的bug，我整整熬夜到凌晨三点，最后发现是Apollo的一个废弃参数问题。那一刻我真的想摔键盘，如果用的是REST，这个问题五分钟就能解决。所以，如果下次有人问我要不要上GraphQL，我会先问他：你的团队真的知道自己在为什么买单吗？
