NextJS 13.4+ SSR环境下自定义API数据获取与缓存方案选型

结论 #

直接使用cache()包装服务层getUser函数的方案（方案2）更适配你的场景，效率更高且贴合Next.js App Router的设计思路。

两种方案对比分析 #

方案1：fetch调用自定义API路由的弊端 #

• 不必要的性能损耗：SSR时服务器内部发起HTTP请求到自身API，会额外经历URL解析、请求处理、数据序列化/反序列化等流程，完全是冗余开销，高并发场景下影响更明显。
• 缓存逻辑重叠：Next.js的fetch默认自动缓存，但你的API路由仅做服务层调用转发，相当于做了两层无意义的缓存，没有额外收益。
• 错误处理冗余：既要处理fetch的响应状态错误，又要在API路由内处理服务层逻辑错误，代码重复度高。

方案2：直接调用cache包装的服务层函数的优势 #

• 性能最优：跳过HTTP中转环节，直接在服务器端执行数据库查询，减少中间层开销，响应速度更快。
• 自动去重与缓存：React的cache()会在同一请求周期内自动去重——如果页面或组件多次调用getUser(id)，只会执行一次数据库查询，避免重复请求。
• 安全性保障：server-only导入确保该函数仅在服务器端运行，不会被打包到客户端代码，杜绝数据库逻辑泄露风险。
• 代码更简洁：省去API路由的中转环节，错误处理更集中，代码维护成本更低。

额外建议 #

如果后续需要将该API对外暴露（供客户端或第三方调用），可以保留API路由，但SSR场景下仍优先直接调用服务层的缓存函数，兼顾内部性能与外部接口需求。

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