如何在Next.js中结合JWT认证使用useFormState？
2026-7-4
解决方案分析：在Next.js Server Action中获取JWT关联用户ID
你的核心需求是在后端Server Action里拿到JWT令牌，解析出用户ID，把表单创建的条目和用户绑定。针对你提到的两种方案，这里分析下各自的优劣和最佳实践：
方案一：在useFormState的initialState中传入令牌
这种方式能实现需求，但存在几个明显的问题：
- 局限性：如果你的JWT是存在HttpOnly Cookie里（这是安全存储的最佳方式），客户端组件根本无法读取到这个令牌，直接就没法用这个方案。
- 安全风险：如果令牌存在localStorage或客户端状态中，把它放到initialState里，会随着表单状态在客户端和服务端之间传递，一旦表单出错返回状态到前端，令牌会暴露在客户端，增加被XSS窃取的风险。
- 维护麻烦：如果令牌有刷新机制（比如过期前获取新token），你需要同步更新initialState，很容易出现令牌不一致的情况。
方案二：全局附加令牌+后端中间件处理（推荐）
这个方案类似Angular的HttpInterceptor，是更符合Web安全规范的做法，分两种场景实现：
场景1：JWT存储在HttpOnly Cookie中（优先推荐）
这是最安全的存储方式，浏览器会自动在所有同域请求（包括Server Action的请求）中携带Cookie，无需前端手动处理：
- 用户登录时，后端设置
HttpOnly、Secure、SameSite=Strict的Cookie，存储JWT。 - 编写后端中间件：在每个请求到达时，从
request.cookies中提取JWT，验证签名并解析出用户ID，把用户ID挂载到请求对象的自定义字段（比如req.userId）。 - 在
createOfferServer Action中，直接通过headers()获取Cookie，或者借助中间件处理后的用户ID，关联到新创建的条目上。如果用NextAuth这类认证库，还可以直接调用getSession()获取用户信息，无需手动解析令牌。
场景2：JWT存储在localStorage中
如果因为某些原因必须存在localStorage，需要前端统一处理请求头：
- 封装全局请求方法（比如自定义fetch或者用axios），在所有请求（包括调用Server Action的请求）的请求头里添加
Authorization: Bearer <你的JWT令牌>。 - 后端中间件从请求头中提取令牌，验证解析出用户ID，挂载到请求对象上。
- Server Action中直接使用该用户ID关联条目。
方案对比总结
| 方案 | 优点 | 缺点 |
|---|---|---|
| 方案一 | 实现简单，无需额外配置 | 安全风险高，依赖客户端可读取令牌，维护麻烦 |
| 方案二 | 安全合规，统一处理认证逻辑，适配所有请求场景 | 需要配置中间件或请求拦截器，初期有少量工作量 |
优先选择方案二，尤其是HttpOnly Cookie的实现方式，既能避免XSS攻击风险，又能让浏览器自动处理令牌携带，减少前端代码的复杂度。
内容的提问来源于stack exchange，提问作者Michał Terczyński
相关产品推荐
相关产品推荐
