Next.js Server Actions 和 Route Handlers 有什么区别？提交数据应该用哪个？

知识点详解：同样修改数据，为什么需要两种入口？

Action 更贴近一次页面交互

假设用户在资料页修改昵称。

Server Action 可以接收表单数据，在服务端检查用户身份和字段，再更新资料。框架负责将页面交互与服务端执行连接起来，也可以配合刷新相关数据或跳转。

它省掉的是部分手工接口胶水，不是省掉网络、安全检查或错误处理。验证失败时，仍需要把用户能理解的错误返回页面；成功时，也要让界面得到确认后的结果。数据修改文档

Action 还应调用清晰的业务函数，避免把所有数据库逻辑都散落在页面入口里。这样以后增加另一种调用者，能够复用规则，而不是复制鉴权和校验。

Route Handler 更贴近明确的 HTTP 约定

假设支付平台向我们发送一个结果回调。调用方不是当前 React 页面，而是一个遵循 HTTP 协议的外部系统。

这时需要确定地址、方法、签名校验、响应状态、超时与重试规则。Route Handler 可以明确接收 POST 请求，再按约定返回响应。

同样，移动端或第三方客户端需要的公开 API，也通常要有稳定的请求与响应结构，而不是依赖页面内部的框架调用细节。Route Handlers 文档

所以，不能只问“它能不能写数据库”。两种入口都能，但它们面对的消费者与约定不同。

写在服务端，不等于浏览器没有风险

假设 Action 接收一个 userId，直接修改这个用户的昵称。

攻击者未必需要点击我们提供的按钮。他可以尝试提交另一人的 ID。服务端必须根据登录身份判断这个人是否允许修改该对象，而不是相信页面已经隐藏了其他人的按钮。

Action 应视为可被请求触发的服务端入口。参数、对象权限和敏感操作都要在服务端核对；框架提供的保护也不能代替业务授权。官方安全说明

Route Handler 同理。两者选择不同，不意味着其中一方自动更安全。

避免让两种入口各写一套业务规则

比较稳妥的组织方式是：入口负责解析请求与身份，业务服务负责规则，数据层负责读写。

比如资料页的 Action 与移动端的 Handler 都调用同一个“修改当前用户资料”服务。这样可保持字段校验和权限判断一致。

但请求签名、HTTP 状态或页面返回值属于各自入口，不必强行统一成完全一样的对象。

这里讲的是 Next.js 的 React/JavaScript 机制。Python 服务可以作为独立 HTTP 后端，但没有可直接照搬的 Next.js Server Action API；不能为了双语言代码而编造对应接口。

面试官继续追问

Server Action 可以用于主要查询接口吗？

不要把它当成所有请求的统一替代品。应区分渲染期间读数据、界面数据修改和对外 HTTP 服务，再采用框架支持的合适方式。

数据库更新成功，但页面还显示旧值怎么办？

继续检查缓存失效和页面刷新路径。入口选择解决的是怎样调用服务端，不保证所有缓存自动更新。相关机制见 Q435。

同一个修改动作既要供页面用，又要供外部系统用，怎么写？

先抽出可复用业务逻辑，再分别建立 Action 与 HTTP 入口，并保留各自认证方式和协议约定。不要把外部系统强行绑定到页面调用协议。

面试速记卡

• Server Action：适合页面交互中的服务端数据修改。
• Route Handler：适合显式 HTTP 接口、Webhook 和外部消费者。
• 网络事实：Action 从浏览器调用时仍有请求。
• 权限边界：身份、参数与对象权限都在服务端检查。
• 代码组织：复用业务规则，不混淆页面协议和对外协议。