Cookie与Session详解：登录状态原理、坑点与Token选型

每个做 Web 开发的，几乎都被同一个问题卡过：明明上个页面还好好的，刷新一下就让我重新登录；明明登录成功了，换个页面又说未授权。等你百度一圈，看到满屏的《Cookie和Session详解》，点进去撸了几千字，似懂非懂，下次遇到还是不知道怎么排查。这篇文章我想换个讲法，不背八股，而是把 cookie 和 session 维持登录状态的原理彻底拆开，从根源说清楚它们各自负责什么、怎么配合、坑在哪里，最后再聊聊现在项目里常用的 token 方案和它们的关系。照着这篇文章的思路走一遍，后面再遇到登录状态相关的问题，你起码知道该往哪个方向查。

适合正在学 Web 开发的新人，也适合写过一阵子 CRUD 但从来没系统梳理过这块的后端同学。我会把关键参数和实际案例串在一起讲，尽量少讲空话，多讲能直接落地的内容。

1. 登录功能失效的根源：HTTP 协议本来就是无状态的

很多人第一次接触 cookie 和 session，是在学习登录功能的时候。写代码的时候明明按教程来了，但怎么也搞不懂：为什么我一个用户登录成功了，服务器却“不认识”我？为什么还需要一个 session 来记录我是谁？

要理解这件事，先得接受一个反直觉的事实：HTTP 协议从设计之初，就压根没想过要记住你。

1.1 无状态协议到底是什么意思

所谓的“无状态”，指的是服务器处理每一个请求时，都是独立的。它不会因为你三秒前发过一个请求，就对你三秒后的请求有额外印象。每个请求到了服务器眼里，都是“初次见面，请多关照”。

我打个比方。你去银行办事，第一次进门，柜员问你：办什么业务？你说办卡。办完了，第二次你再去，柜员照样问你：办什么业务？她不会记得你昨天刚来过。如果你希望她“记得你”，你需要主动出示身份证——而cookie 就是浏览器替你随身带着的那张身份证。

这个过程不是说服务器蠢，而是 HTTP 协议当年设计的时候，场景就是传输静态文档。浏览器请求一个 HTML，服务器回一个 HTML，完事，双方谁也不欠谁。这种设计让 Web 天生就支持海量并发，因为服务器不需要为每个请求额外维护状态。

但发展到今天，Web 上全是需要“认人”的业务：购物车、个人中心、发帖评论、在线支付……这些功能天然就需要状态。于是问题来了：协议层不提供“记忆”，应用层就必须自己想办法。

1.2 “记住你”这件事，核心是要解决三个问题

要在一个无状态协议上造出“登录状态”，本质上是解决三件事：

第一，识别身份。服务器得知道当前请求是谁发出来的。是张三还是李四？

第二，验证身份。服务器不能光听客户端说自己是谁就信。你还得拿出证据，证明你确实是张三。

第三，维持身份。用户不可能每个请求都重新输入一次用户名密码，那样体验太糟糕。验证过一次之后，后续一段时间里的请求，都得能被自动识别为“已登录”。

cookie 和 session 的组合，就是 Web 世界里最经典的一套解决方案：cookie 负责“携带凭证”，session 负责“记录状态”。两者一个在客户端，一个在服务端，各管一摊，配合起来完成“登录后保持身份”这件事。

这里先记住一个关键点：登录状态的本质，不是在客户端放了一个“已登录”的标记，而是服务器记下了“这个会话属于谁”。cookie 里的内容只是用来告诉服务器“我是谁”——真正确认你是谁的判断，在服务端。这一点很多人理解反了，后面排查问题的时候才老找错方向。

2. Cookie：浏览器替你保管的“通行证”

cookie 这个词翻译过来叫“小饼干”，听着人畜无害，但它其实是浏览器里最核心的存储机制之一。从技术角度描述，cookie 是一小段由服务器下发给浏览器、浏览器负责存储并在后续请求中自动回传的文本数据。

2.1 Cookie 从哪来，到哪去

一个典型的 cookie 生命周期是这样的：

第一步，你在浏览器里输入账号密码，点登录，浏览器把用户名密码发给服务器。

第二步，服务器验证通过之后，会在 HTTP 响应头里加一行Set-Cookie，内容一般包含用户标识、过期时间、路径等信息。

第三步，浏览器收到响应后，会把这段 cookie 存到本地。存哪里取决于浏览器实现，在 Chrome 里就是那个 Cookie 数据库文件，在开发者工具的 Application 面板里能看到。

第四步，之后你再去访问这个域名下的任何页面，浏览器都会自动把之前存下的 cookie 放进请求头里，发送给服务器。

第五步，服务器看到请求头里带着 cookie，就能识别出“哦，是之前登录过的那个张三”。

整个过程对用户是完全透明的。你不需要手动做什么，浏览器全自动处理。这也是为什么很多新手对 cookie 感到神秘——你越看不见它，越觉得它玄乎。

2.2 Set-Cookie 响应头：服务器给浏览器的密信

服务器和浏览器之间通过 HTTP 头来“商量”cookie 的事。下发的时候用Set-Cookie，携带的时候用Cookie。给你看一段最直观的响应头示例：

HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: sessionId=abc123xyz; Path=/; HttpOnly; Max-Age=3600

这一行Set-Cookie其实包含了好几层信息：

• sessionId=abc123xyz：cookie 的键值对，这个 key 你随便起名，但实际项目里一般叫 SESSIONID、JSESSIONID 之类。真正存什么内容，是你自己决定的。
• Path=/：表示这个 cookie 在哪个路径下有效。写/表示整个域名下都有效。如果你写/admin，那只有访问 admin 开头的路径时浏览器才会带上这个 cookie。
• HttpOnly：表示这个 cookie 不能被 JavaScript 通过document.cookie读取。这个属性太重要了，后面讲安全的时候细说。
• Max-Age=3600：cookie 的有效期，单位是秒。3600 秒就是 1 小时。1 小时后 cookie 过期，浏览器就会把它扔掉。

浏览器收到这行之后，就会把sessionId=abc123xyz这个键值对以及它关联的属性都存起来。之后你发任何请求到同一个域名，浏览器都会在请求头里加上：

Cookie: sessionId=abc123xyz

服务器这边，框架一般都会帮你解析这个请求头。像 Node.js 里，req.headers.cookie能拿到原始字符串，用了cookie-parser中间件就直接变成对象。Python Flask 里是request.cookies。Java Servlet 里是request.getCookies()。

2.3 Cookie 的关键属性：每个都可能踩坑

cookie 里最容易被忽略的就是那几个属性，因为它们影响到 cookie 能不能被正确发送、能不能被安全保存。我把常用的属性整理成一个表格：

这里特别说一下Domain 和 Path这两个。它们决定了“这个 cookie 在什么请求里会自动带上”。

Domain 默认是当前主机名。比如你登录的是www.example.com，那 cookie 的默认 Domain 就是www.example.com，你在api.example.com下发起的请求是不会自动带上这个 cookie 的。如果你希望子域之间共享登录状态，就需要在 Set-Cookie 里显式指定Domain=.example.com。

Path 默认是当前路径。这个坑我踩过：在/login路径下设置的 cookie，默认 Path 是/login，导致用户登录成功后跳转到/home，请求里不携带 cookie，session 就找不到了，表现为“登录成功但立刻失效”。所以实际项目里，登录成功后设置 cookie，Path 一定要写成/。

2.4 Cookie 的容量与存储限制

还有一点容易被忽略：cookie 的容量非常有限。单个 cookie 大小一般限制在 4KB 左右，一个域名下的 cookie 总数也是有限的（不同浏览器标准不一样，Chrome 大约 180 个）。

这意味着你不能把用户信息、购物车详情之类的大数据都塞进 cookie。cookie 只适合放“标识”，不适合放“数据”。真正的大数据要放服务端。这个限制也是 session 机制能流行起来的原因之一。

3. Session：服务端那张“游客登记表”

cookie 解决了“客户端携带凭证”的问题，但光有凭证还不够。凭证本身是不可信的——浏览器里存的 cookie，用户可以自己改。如果你把“userId=1”直接放进 cookie，那用户手动改一下请求头就能冒充别人了。

Session 机制的设计思路，就是把这个信任问题交给服务端来处理。

3.1 Session 的工作模型：不是数据，而是一张登记表

Session 的机制可以分为三层理解。

第一层，key。服务器在用户第一次访问（或者说第一次“需要被记住”）的时候，生成一个随机字符串，通常叫 session ID。这个 ID 足够长且随机，别人猜不到。它就好比是银行给你的存单号码。

第二层，value。服务器在内存里（或者 Redis 里）维护一张表，以 session ID 为 key，存这个会话对应的用户信息。比如：

{ "abc123xyz": { "userId": 10001, "username": "张三", "loginAt": "2025-01-01 10:00:00" } }

第三层，传递。服务器把 session ID 通过Set-Cookie下发给浏览器保存。之后浏览器每次请求带上 cookie，服务器根据 cookie 里的 session ID 去查这张表，查到就是已登录，查不到就是未登录。

用一个现实中的类比，session 就是游乐园的储物柜：游客把钱和外套放进柜子（服务端存储），锁好，拿到一把钥匙（session ID），把钥匙揣兜里（cookie 里）。之后每次去开柜子，掏出钥匙，服务员一看钥匙上的编号，就知道该开哪个柜子。你不需要把外套（用户数据）带在身上，钥匙（session ID）就够了。

3.2 从登录到访问，一次完整的 Session 流程

把整个过程串起来看，大概是这个顺序：

1. 用户 POST 提交用户名密码。
2. 服务器校验通过，生成一个全局唯一的 session ID。
3. 服务器把 userId 和 username 等信息存入 session 存储层，以 session ID 为 key。
4. 服务器在响应头里通过Set-Cookie下发 session ID，比如Set-Cookie: JSESSIONID=abc123xyz; Path=/; HttpOnly; Max-Age=3600。
5. 浏览器收到并保存 cookie。
6. 用户访问其他页面，浏览器自动带Cookie: JSESSIONID=abc123xyz。
7. 服务器从 cookie 里解析出 session ID，去存储层查，查到 userId 和 username，把这个信息挂到当前请求上下文里。
8. 后端代码里直接读req.session.userId就能知道当前是谁，不再需要重新查数据库。权限校验也基于这个信息做。

这就是“登录状态”的完整闭环。整个过程里，用户名密码只在第 1 步传输过一次，之后所有请求都靠 session ID 来标识。

这带来一个很关键的体验提升：服务器不需要每次都查数据库验证密码，只需要查一下 session 存储，命中就直接放行。对于高并发场景，这个差异非常明显。

3.3 Session 的存储：内存、文件、还是 Redis

Session 存的用户信息放哪儿，这是设计上必须考虑的问题。最简单的方案是放服务器内存里，默认情况下 Java Servlet 容器的 session 就是放内存，Node.js 配合 express-session 默认也是内存存储（MemoryStore）。这种方式速度快、零依赖，但有两个致命问题：

一是容量受限。内存是有限的，每个 session 都占一点内存，用户一多，内存蹭蹭涨。

二是重启丢失。进程一重启，内存里所有 session 全部清空。线上部署最常见的一个问题就是：后端发版重启了一下，所有用户全部被踢下线，要重新登录。

所以稍微上点规模的项目，都不会把 session 放进程内存里，而是集中放到 Redis。Redis 天然支持 key-value 存储和过期时间，而且还解决了多实例部署时 session 共享的问题。我后面专门讲分布式的时候会展开。

3.4 过期时间：把“登录状态”的寿命管起来

Session 不能是永久有效的。如果永久有效，用户忘了退出登录，别人拿到他的 cookie 就能一直冒充他。所以服务端必须给 session 加上过期时间。

这里有两个典型策略：固定过期和滑动过期。

固定过期就是 session 创建后，无论用户怎么操作，到期一律失效。适合安全要求高的系统，比如网银。

滑动过期是只要用户在持续操作，过期时间就自动续期。比如你设置 30 分钟不操作自动退出，但如果你每隔 20 分钟就点一下，它就不会掉线。大多数网站采用的是这个方案。

实现滑动过期，在 Redis 里就是每次请求时重新设置一下 session 的 TTL。在传统内存型 session 里，是每次请求时更新lastAccessedTime，超时判断基于这个时间。

有一点需要提醒：cookie 的 Max-Age 决定了浏览器端存多久，session 的过期时间决定了服务端认多久。两者必须搭配好。有一段经典的不匹配情况：你给 cookie 设置了 7 天过期，但 session 只存了 2 小时。用户隔两天回来，cookie 还在，请求带上了 session ID，但服务端查不到 session，结果还是要重新登录。反过来，cookie 过期早、session 有效期长，那用户就得不定时被踢下线。所以设计登录态时，这个时间要统一考虑，最好做成同一份配置。

4. Cookie 与 Session 的配合：一个记编号，一个查底账

前面把 cookie 和 session 分开讲了，但真正重要的是它们怎么搭配。很多开发者能把两个概念背下来，但一到实际场景就迷糊，不知道该用 cookie 还是该用 session。其实答案非常简单：它俩不是一个层级的方案，session 依赖 cookie 来传递 session ID，cookie 是载体，session 是本体。

4.1 为什么 session 必须依赖 cookie

Session 机制的核心是 session ID 的传递，而 cookie 是传递 session ID 最自然的载体。

你可能要说，我不是在 URL 里也能传 session ID 吗？比如http://example.com/home;jsessionid=abc123。确实有这种方式，PHP、Java Servlet 规范里都支持 URL rewriting 作为 cookie 不可用时的备选方案。但这种方案非常糟糕，session ID 直接暴露在 URL 里，用户可能把链接发给别人、贴在论坛上，等于把钥匙直接送人，太危险了。

所以规范做法就是：cookie 可用的时候用 cookie，cookie 被禁用时才考虑升级方案，现在大多数现代应用干脆不处理禁用 cookie 的情况，直接提示用户需要开启 cookie。

4.2 从浏览器到服务器的完整链路拆解

我用一个真实场景走一遍，方便你从头到尾看清楚：

你在https://example.com/login页面输入账号密码，点击登录。

请求到了 Nginx，Nginx 把请求转发给后端服务。后端服务里执行登录逻辑：

# Flask 伪代码 @app.route('/login', methods=['POST']) def login(): username = request.form['username'] password = request.form['password'] user = authenticate(username, password) if not user: return '用户名或密码错误', 401 session['user_id'] = user.id session['username'] = user.username return redirect('/dashboard')

注意上面 Flask 里session['user_id'] = user.id这行。你表面上是往 session 对象里写数据，框架背后做了三件事：生成 session ID、把数据存服务端存储、设置Set-Cookie响应头。

浏览器收到响应，不只是拿到了页面，还默默地把Set-Cookie: session=xxx存进了自己的 cookie 存储。

然后你点击“我的订单”按钮，浏览器发起/my-orders请求。这个请求头里自动带上了Cookie: session=xxx。

后端框架解析请求头里的 cookie，取出 session ID，拿着它去存储层查找对应的 session 数据。找到之后，把 data 挂载到请求对象上。

你在订单接口的代码里，就能通过session['user_id']拿到当前登录用户的 ID，然后去数据库查他的订单列表。

整个链路里，核心逻辑就一句话：cookie 只负责把 session ID 带来带去，真正用来判定身份的，是服务端 session 存储里有没有这个 ID、以及这个 ID 关联谁。

4.3 版本迭代中的兼容问题：cookie 只在首次登录时刷新

做项目迭代的时候容易遇到一个情况：登录流程本身没改，但用户反馈“更新完之后要重新登录”。常见的原因是你在某次发布时改了 session 的 key 名或生成规则，比如把 session ID 键名从userId改成了user_id，导致服务端解析登录态的逻辑找不到旧数据，就当作未登录处理。

另一种更隐蔽的情况：你用了新的 cookie 属性配置，比如以前SameSite=None，现在改成SameSite=Lax，跨站请求不携带 cookie，旧会话在第三方网站环境下就失效了。这类问题排查起来很费劲，因为浏览器本地其实还有 cookie，只是不发送了。下次遇到“本地明明能查到 cookie 但请求里没有”的诡异现象，优先查 SameSite 和 Secure 属性。

5. 实战排查：登录状态老丢，问题到底出在哪

到了这一步，原理和流程基本都清楚了。但真正的挑战在于：你接手一个项目，用户反馈登录状态不稳定，一会儿掉线，一会儿又正常。这时候怎么定位？我把自己排查这类问题的完整思路整理出来，按顺序走，命中率很高。

5.1 第一板斧：先看浏览器实际带没带 cookie

打开 Chrome DevTools 的 Network 面板，刷新页面，点开任意一个请求，看 Request Headers 里有没有Cookie字段。

如果没有 Cookie，说明浏览器压根没存这个域名下的 cookie，或者没权限发。这时候去 Application 面板看 Cookies，确认有没有 cookie 条目：

• 如果是空的，说明 Set-Cookie 压根没下发成功，问题出在服务端响应。
• 如果有数据，但请求里不带，多半是 Domain、Path 或 SameSite 属性不匹配。

如果有 Cookie 但登录状态还是失效，问题大概率在服务端 session 存储层——session 过期了、Redis 里没了、或者多台服务器之间 session 不同步。这种就要看后端日志，确认服务端有没有查到这个 session ID。

5.2 第二板斧：区分“永久 cookie”和“会话 cookie”

打开 Application 面板看 cookie 的 Expires / Max-Age 列。如果显示 Session，说明这是个会话级 cookie，特点是你关掉浏览器它就没了，下次打开浏览器就得重新登录。

这是很多用户口中“我明明勾了记住我，为什么还要重新登录”的常见原因。你在Set-Cookie时没给Max-Age或Expires，浏览器就按会话 cookie 处理。要“记住我”，必须给 cookie 设置过期时间：

Set-Cookie: session=xxx; Path=/; Max-Age=2592000; HttpOnly

上面的意思是让 cookie 活 30 天，关浏览器不会丢。

顺带说一句，从 Chrome 91 版本开始，SameSite默认值是Lax，如果你需要跨站发送 cookie（比如第三方支付回调），必须显式设置SameSite=None; Secure。这里有个前提：SameSite=None必须搭配Secure，否则浏览器直接拒绝设置。这也是从 Chrome 80 之后的硬性规定。如果你在本地用 HTTP 调试跨站 cookie，会被卡得很难受——因为Secure属性只在 HTTPS 下生效。所以本地调试跨站场景，建议用 localhost（chrome 对它睁一只眼闭一只眼），或者直接配置 HTTPS。

5.3 第三板斧：跨域请求带不带 cookie，得用 withCredentials

前端用 Ajax 请求后端接口时，如果前端页面域和后端接口域不一致，属于跨域请求。跨域情况下，浏览器不会自动在请求里带上目标域的 cookie。这时候你需要做两件事：

前端，用 XMLHttpRequest（包括 axios 和 fetch）时要显式开启携带凭证：

// axios 开启 withCredentials axios.get('https://api.example.com/userinfo', { withCredentials: true });

后端，CORS 响应头里要明确允许凭证：

Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true

特别注意：Access-Control-Allow-Origin不能是*，必须是明确的源地址。Access-Control-Allow-Credentials: true和Access-Control-Allow-Origin: *同时出现浏览器会拒绝响应。这两条不配对，是跨域场景下登录状态失效的头号原因。

5.4 第四板斧：服务器重启、多实例下的 session 消失

如果排查到最后，发现 cookie 正常、浏览器正常，但服务端就是查不到 session，那就要考虑阶段性的问题：session 存哪里。

单机部署、session 存内存，只要重启一次进程，所有 session 归零。用户体验就是“一到半夜发版之后，全公司的人都登录失效了”。

稍微上点规模的架构，后端通常是多实例部署在负载均衡后面。这种情况下 session 存单机内存有一个致命问题：负载均衡把请求分摊到多台机器上，用户第一次请求打到 A 机器，session 存在 A 机器内存里；第二次请求打到 B 机器，B 机器内存里没有这个 session，用户就掉线了。

这时候有几个解决方案，按适用场景排序：

方案一：Session 粘连（Sticky Session）。通过负载均衡配置，让同一个用户的请求一直落到同一台机器上。Nginx 里可以用ip_hash或者基于 cookie 的会话保持。这个方案简单，但缺陷是某台机器挂了，上面的 session 就全丢了。

方案二：Session 复制。在多个实例之间同步会话数据，比如 Tomcat 集群的 DeltaManager。这个方案适合实例数量很少的情况，实例多了同步成本指数级上升。

方案三：集中式 Session 存储。把 session 从进程内存挪到独立的存储层，比如 Redis。所有实例都往 Redis 读写 session，不存在不同步问题，实例挂了也不丢。这是目前最主流的方案。Spring Session 就是把 Session 持久化到 Redis 的现成实现；Node.js 里 connect-redis 配合 express-session 也是这个思路。

实际项目中，方案三基本是首选。这里额外提醒一个坑：Redis 的过期策略和 Session 的过期时间要对应。如果你用SETEX session:{id} 3600 data设置一小时过期，那 session 固定一小时后失效，不管用户一直在不在用。如果你要做滑动过期，需要在每次访问时刷新 TTL：

# 每次用户请求时，重置过期时间 EXPIRE session:abc123xyz 3600

5.5 别忽略“会话固定攻击”这种安全细节

讲完排查思路，我要补一个安全上的细节，因为它真的会在生产环境咬人。

什么是会话固定攻击？看一个场景：攻击者先自己访问你的网站，拿到一个合法的 session ID（他掌握了这个 ID 的值），然后诱导受害者用这个 session ID 去登录。如果服务器在登录成功后没有“换一个新的 session ID”，而是沿用旧 ID，那攻击者手里的那个 ID 依然有效——因为他和受害者共用同一个会话，攻击者就能看到受害者的登录态了。

防御措施非常简单：登录成功后，强制更换 session ID，旧 ID 作废。主流框架基本都提供现成方法，比如 PHP 的session_regenerate_id()，Java Servlet 3.0 之后的request.changeSessionId()。开发完登录功能后，一定要确认有没有调这些方法。

另一个容易踩的安全点是不设置 HttpOnly。你可以打开浏览器 F12，在 Console 里执行一下document.cookie，如果你的 session cookie 直接明文显示出来了，说明你漏设了 HttpOnly。这意味着页面里只要存在一个 XSS 漏洞，攻击者一行代码就能偷走你的登录态，后面啥都不需要了。

6. 从“掌握原理”到“方案选型”：Cookie + Session 和 Token 怎么选

八股文讲到这里其实可以收了，但经常会有同学问：现在不都在说 token 吗？JWT 和 session 是什么关系？我要不要再学一套新的？我的建议是：先别急着把 session 推倒重来，你要先搞清楚它们解决的是不是同一个问题。

6.1 Token 到底是哪一层的“升级”

Session 模式的核心是“会话状态保存在服务端，客户端只持有 ID”。Token 模式的核心是“把用户信息经过签名后直接给客户端，服务端验证签名，不保存状态”。

这两者的差别可以浓缩为一张表：

看到了吧，token 的最大优势并不是“比 session 安全”——它和 session 是两种取舍。Token 无状态，意味着后端不用维护大量会话数据，尤其适合微服务架构里多个服务共享认证信息。但无状态也带来一个麻烦：一个 token 签发之后，在过期之前你没法单方面让它失效，除非你引入黑名单机制——而这一引入，无状态的优势就打了折扣。

6.2 什么场景适合 Cookie + Session，什么场景适合 Token

没有绝对的好坏，只有合不合适。我根据自己的项目经验，给几个比较务实的建议。

优先选 Cookie + Session 的场景：

• 传统 Web 应用，后端渲染页面，前端就是页面加一点脚本。这种情况下 cookie 自动携带，不用前端代码做什么。
• 登录态需要被服务端实时控制，比如封号、踢人下线的需求。封号就是删 session，立刻生效。
• 使用场景集中在浏览器，不需要做复杂跨端（比如小程序、iOS、Android）。

优先选 Token 的场景：

• 前后端分离，前端是 SPA 或移动端 App，尤其涉及多客户端共享同一套认证接口。
• 后端服务拆分为多个微服务，希望认证逻辑统一、服务间调用不反复查会话存储。
• 需要对接第三方开放平台、OAuth 等场景，token 承载身份更灵活。

举个具体例子，我做过一个后台管理系统：前后端分离，前端是 Vue 部署在 CDN，后端是 Java Spring Boot 集群部署。这种架构下如果我用 session 方案，就必须处理跨域携带 cookie 的问题，还要保证 Nginx 和后端服务之间正确传递 cookie，同时后端多实例之间还要想办法共享 session。项目工期紧，我直接改用 JWT 方案，前端每次请求把 token 放请求头里，后端用一个拦截器统一验签，省掉了 session 共享的复杂度，也没有跨域 cookie 的困扰。这是非常典型的 token 适用场景。

但另一个项目是传统电商网站，服务端渲染页面，用户登录后要维持购物车状态，还要支持“强制下线”这类运营操作。这种情况 session 就是最顺手的，cookie 自动带，服务端要踢人就删掉对应用户的 session 数据，比 token 方案好控制得多。

6.3 不盲从“Token 万能论”

有些文章把 token 捧上天，把 session 贬成老古董，这种说法害人不浅。你只要想一想：Cookie + Session 在互联网上跑了几十年，几乎所有的传统 Web 应用都是这个方案，稳定性有目共睹。很多“Token 更好”的说法，其实混淆了“Token 本身”和“JWT 的易用性”。

Token 方案有一个隐藏缺陷是很多新手没意识到的：因为服务端不保存状态，所以你没法控制这个 token 的“单点登录”能力。用户在你这边修改了密码、被封了号，或者你希望用户“所有设备退出登录”，在纯 Token 方案里，之前签发的 token 在过期前依然有效。要实现即时失效，得维护一套黑名单或 token 版本号机制——这和 session 的“删掉即失效”相比，是额外的一层复杂度。

我见过不少团队，本来一个好好的 session 方案跑了好几年没问题，因为听人说 token 先进，硬生生重构了一遍，结果引入了刷新 token 过期、泄露、被重放等一堆新问题。重构完折腾了大半年才稳定下来。所以如果你是那种做一个常规 Web 应用的团队，先想清楚自己是不是真的需要跨端、无状态和微服务共享，如果不需要，Cookie + Session 完全够用，千万别为了技术而技术。

7. 登录状态方案的后续演进：从单会话到多端登录控制

讲完 Cookie + Session 和 Token 的选型，聊一个实际项目里早晚会遇到的需求：多端登录控制。也就是“同一个人用手机、电脑、平板同时登录”这种场景，怎么设计。

7.1 同一账号多处登录，session 会不会串

先说结论：session ID 是独立的，互不干扰。用户电脑登录一次，生成一个 session ID；手机再登录一次，又生成一个 session ID。两个 session 都关联到同一个 userId，但互相独立。

问题出在“强制单端登录”这个需求上。比如网银要求一个账号同时只能在一个设备上登录，新的登录了，旧的必须踢下线。

如果你用的是服务端 session，这个需求很容易实现：把用户 ID 和当前 session ID 的映射关系存起来。新登录的时候，更新这个映射，然后去旧 session 里标记个“已失效”状态，或者直接删除旧 session。下次旧设备一旦带旧 session ID 来访问，服务端一查，发现 session 已经被删了或标记失效，就返回未登录。

如果用纯 JWT 做登录态，这个需求就得配合“token 版本号”来做。用户在服务端有一个 token 的版本号字段，每次登录把版本号加一，签发 token 时把版本号放进 token 的 payload 里。服务端在验签时顺便比对版本号，版本号不一致就拒绝。新登录把版本号加一后，旧的 token 版本号就落后了，直接被拒绝。

7.2 记住我 vs 安全性的平衡

还有一个平衡问题：登录态的持久化时间。

“记住我”功能本质上是延长登录态的有效期。最简单的实现是给 session 的过期时间设置得更长，比如 30 天。但风险在于：如果用户的 cookie 被窃取，攻击者有 30 天的时间可以冒充用户。

更稳妥的做法是分级：不勾选“记住我”，用会话级 cookie，关浏览器就失效，安全要求高；勾选“记住我”，才签发长有效期的 cookie。很多系统用“双 token”方案——短期 token 用于日常请求，长期 refresh token 用于自动续期，而且 refresh token 每次使用时都会轮换，泄露风险被压缩到很短的有效期内。

这个方案有点复杂，但它是现代 Web 应用主流的设计方向。如果你在做一个用户量不小的产品，建议提前把“刷新令牌”的机制规划进去，别等上线之后出安全问题再补救，那时候想改认证体系，改动面非常大。

7.3 用一张时序图思想来记住全流程

写代码前，只要在脑内过一遍这个流程，基本不会出错：

1. 用户登录提交凭证。
2. 服务端验证凭证，成功后创建会话记录（session 或 token）。
3. 服务端通过 Set-Cookie（session 方案）或响应体返回 token（token 方案）交给客户端保存。
4. 后续每个请求，客户端自动（cookie）或手动（Authorization 头）携带凭证。
5. 服务端每次请求都校验凭证，有效则放行，并提供当前用户信息。
6. 凭证过期、注销、被篡改，则返回未登录，提示重新登录。

理解了这个骨架，任何具体的框架、中间件都只是这个流程的某种实现。你去看 Spring Security、Express-session、Flask-Login 的文档，会发现万变不离其宗。

8. 关于 Cookie 与 Session 的最后几句实操心得

说实话，cookie 和 session 这个八股文题目，每个程序员都看过，但真正遇到线上问题，能把知识点用起来的人不多。原因在于：很多文章只讲概念，不讲场景。概念是“恒温箱里的知识”，场景才是“战场上的本领”。结合我自己的经历，这里做几条操作层面上的收尾建议。

第一，排查登录问题，永远先分“三层”排查。第一层是客户端有没有正确存储和送出 cookie 或 token；第二层是网络链路有没有把身份凭证安全送到服务端（包括 Nginx、网关层是否拦截了 Cookie）；第三层是服务端有没有正确处理和校验。大约八成的登录问题在前两层就定了性，根本轮不到看后端代码。

第二，安全配置宁可过度，不要缺失。所有登录相关的 cookie，默认都设置HttpOnly、Secure，生产环境一定要 HTTPS。SameSite属性根据业务设置成Lax是比较稳妥的默认值，它能防一大部分跨站请求伪造（CSRF）攻击。不要因为省配置麻烦，把这些省略掉。

第三，登录成功后记得换 session ID。这个是我见过很多项目漏掉的一步。如果你用的是框架默认加密 cookie session（比如 Flask 的客户端 session、Express 的默认 session），特别要注意这一点——防止会话固定攻击，属于成本最低但收益极高的安全措施。

第四，用真实流量复盘“用户为什么老掉线”。如果用户的反馈是“用着用着就被踢下线”，别急着怪网络、怪浏览器，先去看服务端日志里的 session 失效原因，是过期了？是被踢了？还是 session 存储炸了。大部分“掉线”本质上不是 bug，而是过期策略和用户预期的冲突。你要么调整过期时间，要么在界面上给个友好提示，让用户不困惑。

Web 登录状态的原理说复杂其实并不复杂：一个在客户端记编号，一个在服务端查底账，两个配合，把无状态的 HTTP 协议硬生生“变”成了有状态的 Web 应用。希望这篇文章能帮你把这个概念彻底建立起来，下次不管是自己搭登录，还是排查线上登录问题，都能一眼看到底。