Cookie由浏览器自动通过请求头发送，服务端在SSR渲染前解析req.headers.cookie或调用cookies()验证身份，并注入用户信息；需配置Secure、SameSite=Lax、Domain一致以确保正确传输。
在服务端渲染（SSR）中，Cookie 本身不会“主动传递”，而是由浏览器在发起 HTTP 请求时，自动通过 Cookie 请求头将已有的域名匹配 Cookie 发送给服务端。因此，认证凭证（如 sessionid、auth_token）只要以 Cookie 形式安全存储（HttpOnly=false、Secure、SameSite=Lax/Strict），就能在 SSR 的每次页面请求中被服务端读取并用于身份验证。
服务端如何从请求头读取 Cookie
Node.js（如 Express、Next.js API Route、Nuxt Server Middleware）收到请求时，Cookie 存在于 req.headers.cookie 字符串中，格式为 key1=value1; key2=value2。需手动解析或借助中间件：
- Express 中可用
cookie-parser中间件：解析后挂载到req.cookies对象 - Next.js App Router 的 Server Components 或 Route Handlers 中，通过
cookies()函数（来自next/headers）直接获取解码后的 Cookie 值 - 纯 Node.js 可用
document.cookie的服务端等价物 —— 手动解析字符串（不推荐）或使用cookie包的parse()方法
SSR 渲染前完成认证校验
关键是在服务端生成 HTML 前，就完成用户身份识别，以便注入用户信息（如用户名、权限）或跳转登录页：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在数据获取阶段（如
getServerSideProps、generateStaticParams+dynamic、async server component）读取 Cookie 并验证 session/token - 若验证失败，可返回重定向响应（如
redirect('/login')）或渲染未登录视图，避免客户端闪屏 - 验证成功后，把用户信息作为 props 传入页面组件，实现真正的服务端个性化渲染（如显示“欢迎，张三”）
注意 Cookie 安全与同源约束
以下配置直接影响 SSR 场景下 Cookie 是否能被正确发送和读取：
立即学习“Java免费学习笔记（深入）”；
-
Domain 和 Path：确保前端设置 Cookie 时的
domain与 SSR 服务域名一致（如都为.example.com），否则浏览器不会携带 -
SameSite：SSR 页面首次加载属于“跨站 GET”，建议设为
Lax（默认），保证导航类请求能带 Cookie；设为Strict会阻止大部分跨站场景 -
Secure：生产环境必须开启，确保 Cookie 仅通过 HTTPS 传输（本地开发可配合
http://localhost使用SameSite=Lax+ 无Secure） -
HttpOnly：若只需服务端验证（如 session ID），建议设为
true；若前端 JS 也需要读取（如用于 API 请求），则设为false
前后端 Cookie 同步的常见误区
开发者常误以为要“手动把 Cookie 从客户端发给服务端”，其实无需额外操作：
- 浏览器访问
https://example.com/dashboard时，只要该域名下存在有效 Cookie，就会自动带上Cookie: sessionid=abc123头 - 不需要在
fetch或axios中显式设置credentials: 'include'—— 这是客户端 JS 请求才需要的；SSR 的初始 HTML 请求是浏览器原生导航，天然携带 Cookie - 但后续客户端发起的 API 请求（如点击按钮触发的
fetch），仍需配置credentials: 'include'才能复用同一套 Cookie 认证
