Next.js 13中调用外部API：服务端还是客户端？附数据重验证疑问

你纠结的核心其实是：既然Supabase已经提供了现成的API，为什么还要多一层Server Actions/Route Handler？下面直接拆解两种方式的差异和适用场景，帮你理清官方建议的逻辑：

直接在客户端调用Supabase API的优劣势 #

• 优势：
  • 流程简单直接，不用额外写中间层代码，省事儿
  • 用Supabase客户端SDK就能快速搞定数据交互，不用自己搭API
• 劣势：
  • 安全隐患：虽然Supabase有RLS（行级安全）和匿名密钥，但客户端的密钥还是可能被扒出来，被人恶意刷请求，导致限流甚至额外成本
  • Next.js重验证用不上：Next.js的revalidatePath、revalidateTag这些服务器端重验证功能，只对服务器端获取的数据生效，客户端调用的话，得自己写缓存失效逻辑（比如靠React Query的缓存规则）
  • 敏感逻辑藏不住：如果要在请求前后做权限校验、数据加工，客户端代码容易被逆向解析，不安全

通过Server Actions/Route Handler调用Supabase API的优劣势 #

• 优势：
  • 安全更靠谱：Supabase的服务端密钥可以存在服务器环境变量里，不会暴露给前端；还能在服务器层加自定义权限校验、请求过滤，把安全关把得更严
  • 完美适配Next.js重验证：服务器端拿的数据可以直接用Next.js的缓存和重验证机制，比如在Server Actions里调用revalidatePath，或者在Route Handler里设revalidate参数，数据更新自动搞定
  • 逻辑集中好维护：所有数据请求逻辑都放服务器端，以后改需求、换数据源，只动后端代码就行，前端不用跟着改
• 劣势：
  • 多写一层代码：得额外开发Route Handler或Server Actions，增加了工作量
  • 服务器负载增加：客户端的请求都要经过服务器转发，会消耗更多服务器资源

给你的具体建议 #

• 如果你的应用是纯公开内容（比如博客、资讯），没什么敏感数据，也不需要复杂权限，直接客户端调用Supabase API就够了，配合RLS做基础控制就行
• 要是涉及用户敏感数据、需要自定义权限逻辑，或者想用上Next.js的服务器端重验证功能，那优先选Server Actions/Route Handler的方式，把敏感逻辑和重验证都放服务器端处理

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