很多后端朋友应该都有这种经历面试前把cookie和session的八股文背得滚瓜烂熟——“cookie存在客户端session存在服务端”“session比cookie安全”……结果一到线上排查登录态丢失或者联调时发现cookie死活存不上立刻满头问号。说实话cookie和session这套机制不算难但知识点非常碎面试官喜欢从各个角度追问业务里稍不留神就踩坑。这篇文章我就从原理到实战把cookie和session维持登录状态的完整链路拆开讲清楚既能应付面试也能帮你解决实际开发里的诡异问题。1. 从HTTP无状态说起为什么登录非得靠cookie和session1.1 无状态协议下“你是谁”到底怎么证明HTTP协议本身是无状态的这句话你在任何一本计算机网络书里都能看到。它真正的含义是服务器对每一次HTTP请求的处理都不会参考上一次请求的任何信息。你连续访问同一个接口十次服务端眼里这十次请求是十个完全不同的陌生人彼此之间没有任何关联。这带来的问题很直观用户输入用户名密码登录成功之后浏览器和服务器的“认识”关系就结束了。下一次再访问个人中心、购物车这些需要身份判断的页面时服务器根本不知道你是谁只能返回“未登录”逼着你重新输入一遍账号密码。这显然无法忍受。我常用生活里的场景来解释你住的小区有门禁保安看到熟人会直接放行。但HTTP协议下的服务器就像得了失忆症的保安每次你走到门口它都一脸茫然地问“你是谁”。你需要一种机制让保安在第一次核实身份后在你的手上盖个章或者在他的值班本上记一笔之后你每次进小区他一扫就知道“哦这个人通过验证了”。Cookie和Session就是Web世界里的“章”和“值班本”。1.2 一个管客户端一个管服务端两者天生就是搭档把登录态拆开来看需要解决三个问题身份怎么标记、标记存在哪里、怎么验证。Cookie和Session一起就是为了回答这三个问题。Session是服务端的“值班本”它保存的是用户的会话数据比如用户ID、角色、过期时间。每次创建Session时服务端会生成一个唯一的ID也就是Session ID然后把自己记在值班本里。Cookie是浏览器端的“章”它负责保存这个Session ID。服务端通过响应头把Session ID发给浏览器浏览器存到本地之后每次请求都会自动把这个ID带回给服务端。服务端拿到ID去自己的Session仓库里查一下发现有记录、没过期就确认了身份。整个过程不需要用户每次重新输入密码。我见过不少新手把Cookie和Session对立起来问“到底用哪个”其实它们是配套使用的。Session负责真正存储数据Cookie负责传递身份标识。哪怕后来出现Token方案本质上也是“客户端保存凭证服务端校验凭证”的模式只是凭证的生成、存储和校验方式变了而已。2. Cookie原理拆解浏览器里那张“小纸条”2.1 一次登录流程里Cookie到底怎么流转完整走一遍流程比背概念有用得多。假设前端在登录页提交了用户名密码后端校验通过然后设置Cookie整个交互过程如下第一步用户登录服务端校验成功。第二步服务端返回响应时带上Set-Cookie响应头。HTTP/1.1 200 OK Content-Type: application/json Set-Cookie: sessionIdabc123; Path/; HttpOnly; Max-Age7200; SameSiteLax {code:0,msg:登录成功}这里就是整个流动过程的起点服务端通过Set-Cookie告诉浏览器“请在本机保存一条记录键是sessionId值是abc123将来访问符合条件的请求时带上它”。第三步浏览器收到Set-Cookie后会根据属性决定如何保存这条Cookie。第四步用户后续发起新请求浏览器自动把符合条件的Cookie放在请求头里一起发出去。GET /api/user/info HTTP/1.1 Host: www.example.com Cookie: sessionIdabc123服务端从请求头里取出sessionId去Session存储中查找对应数据。找到了就知道当前请求属于哪个用户没找到就当成未登录处理。第五步用户退出登录服务端删除Session并要求浏览器清理Cookie。流程看起来简单但里面每一个属性都会影响Cookie能不能存、能不能带、能不能被读取。很多线上问题根源就是某个属性配置不对。2.2 关键属性逐个过很多坑都出在这几个地方Cookie属性是最容易出问题的部分也是面试官最爱往深里问的部分。下面这张表是我整理的属性速查属性作用经验值Domain指定Cookie发送到哪些域名默认当前域名子域名需明确指定父域Path指定Cookie发送到哪些路径默认当前路径登录态通常设为/Expires / Max-Age有效期会话级Cookie不设置这两个值关浏览器就失效持久化Cookie才设置HttpOnly禁止JavaScript读取Cookie登录态必开Secure只允许HTTPS下传输生产环境建议开启SameSite限制跨站请求是否携带防止CSRF的重要防线Domain和Path最常踩坑。假设你登录的是app.example.com后端设置Cookie时没写Domain那Cookie只对app.example.com生效。如果你还有一个admin.example.com两个域名之间是拿不到对方Cookie的。解决方式是在设置Cookie时显式指定Domain.example.com就能让所有子域名共享。但这里有个隐蔽问题如果后端在多个子域名间互相跳转Cookie里存储的不应该是用户密码之类的高敏感信息而应该只是一个Session ID。因为子域名范围扩大意味着任何子域名的脚本如果可注入都有机会访问到共享的Cookie除非你设置HttpOnly。HttpOnly很关键。一旦设置JavaScript里通过document.cookie就读不到这个Cookie了。这能有效阻止恶意脚本偷走登录凭证。我见过不少项目为了图方便把登录凭证直接放localStorage然后被XSS脚本一把梭全部拖走风险极大。Cookie加HttpOnly并不能完全杜绝XSS但至少能把凭证的暴露面缩小一大截。没有设置Expires或Max-Age的Cookie是会话级Cookie浏览器关闭后就会消失。很多用户抱怨“一关浏览器就要重新登录”不一定是Session过期很可能是Cookie没设置持久化时间被浏览器当成了临时Cookie。反过来如果Cookie设置了很长的Max-Age但服务端Session提前过期用户还是会收到“登录状态已失效”的提示所以Cookie和Session的有效期要搭配着来。2.3 中文、大小限制、第三方Cookie三个容易忽略的细节第一个细节Cookie里存中文会出问题。按RFC规范Cookie的键和值不允许出现空格、分号、逗号、中文这些特殊字符。最典型的场景就是前端把用户名直接通过document.cookie name张三写进Cookie当时看着没问题但请求发出去后服务端解出来的可能是乱码或者整个请求被浏览器拦截。正确做法是先编码const value encodeURIComponent(张三); document.cookie username value ; Path/;服务端取出来时对应做decodeURIComponent。网上搜“cookie中文”几乎全是这个问题的求助帖。第二个细节Cookie不是无限量的。单个域名下的Cookie总数通常限制在20到50个左右不同浏览器有差异单个Cookie大小一般不能超过4KB。也就是说你不可能把一份很长的用户信息都塞进Cookie。这也是为什么登录态的设计思路永远是“Cookie里只放一个ID具体数据放服务端”而不是把用户资料全量塞给浏览器。第三个细节第三方Cookie正在被浏览器逐步限制。现代浏览器会把按照用户访问域名来判断Cookie是“第一方”还是“第三方”。举个例子你在a.com的页面上嵌入了b.com的接口这个请求携带的b.com的Cookie在a.com的上下文里就算第三方Cookie。Chrome和Safari都开始默认拦截第三方Cookie对广告跟踪影响最大对正常的单点登录跨域跳转也有影响。很多人遇到“微信里打开网页登录正常在浏览器里打开就跳过头”或者“跨域跳转后Cookie突然没了”多半是被第三方Cookie限制策略波及。3. Session机制拆解服务端到底记住了什么3.1 Session从创建到销毁完整生命周期Session的生命周期可以从五个时间点来看创建。严格来说Session不是“登录成功才创建”的。很多Web框架里当客户端第一次访问某个会用到Session的接口时服务端就会创建一个Session生成Session ID并通过响应头下发。也就是说匿名访问也可能产生Session只是里面没存用户数据。等到用户登录成功再把用户ID等数据写进这个Session里。存储。Session数据保存在服务端默认情况下很多框架存在进程内存中。它的结构本质是一个MapSessionId, SessionData通过Session ID直接命中一条记录读取速度快但内存占用随会话数增长而增长。传递。大多数情况下Session ID通过Cookie在浏览器和服务端之间往返。如果浏览器禁用了Cookie老方案是URL重写也就是把Session ID拼到URL参数里。这个方案现在基本废弃因为Session ID出现在URL里太容易泄露而且会被日志记录、被分享链接带出去。过期。服务端会为Session设置闲置超时时间。我见过Spring Boot默认的Tomcat是30分钟意思是用户连续30分钟没有任何操作Session就会失效。注意这个时间是“闲置时间”不是“总存活时间”用户每发一次请求有效时间都会向后顺延。销毁。用户点击退出登录时服务端应主动删除Session不能只依赖过期。如果服务端不删Session会一直留在内存里直到超时高并发场景下这些“僵尸Session”会占满内存。所以正确做法是调用Session的invalidate()把数据彻底清掉。3.2 Session ID 怎么传藏着哪些风险Session ID是整个会话机制里的根凭证。服务端靠它区分身份攻击者最想拿到的也是它。我见过很多八股文说“Session存服务端比Cookie安全”这个说法不够准确。Session数据在服务端确实比Cookie在客户端安全但Session ID本身是明文在网络上传输的。如果通讯是HTTP明文中间人可以截获Cookie拿到Session ID然后直接冒充用户这就是经典的“会话劫持”。这也是为什么生产环境必须启用HTTPS同时给Cookie加上Secure属性。Secure的意思是“只允许通过HTTPS发送”如果页面是HTTP访问浏览器根本不会把带Secure属性的Cookie塞进请求头里。很多人本地调试时发现Cookie设置失败第一反应是后端代码写错了其实很可能就是页面地址还是http://localhost而设置Cookie时带了Secure。另外要提醒一点登录成功后有条件的话最好更换一次Session ID。在Java的Servlet规范里有changeSessionId()方法其他语言也有类似API。这么做的原因是防止“会话固定攻击”如果攻击者先拿到一个无效的Session ID诱导用户带上它登录登录成功后如果不换ID攻击者手里的这个ID就变成了有效凭证可以畅通无阻。3.3 分布式环境下Session失效的真相与解法我在前面的例子里一直假设只有一台后端服务器。但真实项目基本不会这么简单要么负载均衡挂了多台应用服务器要么微服务拆成了多个节点。这时候Session的一个经典问题就暴露出来了用户第一次请求被负载均衡转发到A机器Session存在了A机器第二次请求被转发到B机器B机器上没有这个Session用户就被判定为未登录。解决思路有三个方向会话粘滞Sticky Session。让负载均衡按某种规则例如根据IP或自定义标识把同一个用户的请求始终转发到同一台机器。优点是实现简单缺点是这台机器挂了用户的Session就彻底丢了而且整个集群的会话数据分布不均匀。Session复制。一台机器更新了Session同步给集群中其他所有机器。这是在早期集群规模不大时用过的方案比如Tomcat的DeltaManager。但数据量大、节点增多时同步开销和网络流量会爆炸现在已经不是主流。集中式Session。把Session数据抽出来放到独立的中间件里最常见的是Redis所有应用服务器都从Redis读写Session。这是目前生产环境最主流的做法。Redis自带过期时间天然契合Session的寿命控制读写性能也足够应用服务器无论怎么扩容缩容都不影响已登录的Session。我之前在项目里就是用的Redis方案核心思路是这样的// 用Spring Session的Redis实现后原本的request.getSession()不变 // 只是底层的Session数据自动落到了Redis里。 Bean public RedisIndexedSessionRepository sessionRepository(RedisTemplateString, Object redisTemplate) { return new RedisIndexedSessionRepository(redisTemplate); }Spring Session帮了大忙应用代码里不需要单独改造Session的创建、更新、过期都由框架统一处理。但要注意两个坑一是Redis实例不能也宕机否则所有登录态同时消失所以生产环境要做高可用二是Session序列化时要保证对象可序列化否则存取直接报错。4. Cookie、Session、Token对比面试八股常问的这些点4.1 一张对比表看懂三者本质区别面试里“Cookie、Session、Token的区别”属于默认送分题但很多人答得粗。下面这张表是我自己整理的面试时照着说基本不会乱维度CookieSessionTokenJWT等存储位置浏览器客户端服务端客户端通常是Header或本地存储数据内容可以是任何小段文本但不应放敏感信息会话数据可存任意结构化对象编码后的身份信息可携带声明是否可被篡改可篡改服务端必须校验服务端集中管理可信度高通过签名防篡改密钥不可泄露性能开销无额外存储开销服务端有内存/Redis开销无存储开销但密钥校验有CPU开销跨域支持Cookie跨域受限依赖Cookie传递ID同样受限可以在请求头里主动携带跨域相对灵活服务端扩容无影响需要集中式存储方案无影响天然适合分布式安全性受XSS影响受会话劫持影响受Token泄露影响过期前难作废这里有个容易说错的点Token方案是不是完全替代了Session其实不是非此即彼。Token出现的一个重要原因是纯CookieSession方案在移动端、跨域场景下越来越别扭。你拿着一个Session ID发给App端App里还得自己维护Cookie存储还经常被各种网络库搞得不兼容。Token只需要客户端在每次请求时放到Authorization头里服务端校验签名即可使用起来简单许多。4.2 面试里关于“安全性”的高频追问追问一“为什么说Session比Cookie安全”这个说法要拆开说。Cookie本身是客户端可控的用户完全可以自己篡改Cookie内容。如果你把“viptrue”写进Cookie用户改成“viptrue”把页面一刷新后端不校验来源的话就穿帮了。而Session数据存在服务端用户改不到只能被动的拿着Session ID去换取服务端数据。安全性的差距体现在这个“数据是否可被用户直接篡改”上。追问二“Session ID被偷了会怎么样”攻击者拿到Session ID后直接在自己的浏览器里构造Cookie请求服务端一查Session还在、还没过期就会把这个请求当成你的请求来处理。这就是会话劫持。解决思路是刚才说的用HTTPS防止中间人窃听给Cookie加HttpOnly防止XSS偷取登录后变更Session ID防止固定设置合理过期时间缩小攻击窗口。追问三“Token和Session哪个好作废”Session好作废。服务端只要把Session记录一删这个会话马上失效。JWT这个无状态Token的弱点恰恰在于签发之后在过期时间之前很难主动作废因为服务端没有保存任何状态。想要让JWT失效要么引入黑名单机制要么把有效期设得很短再配合刷新Token。这是面试追问的高发区能有意识地说出这个缺点面试官会认为你是真的做过项目。4.3 为什么现在项目越来越爱用Token/JWT我自己的感受是项目里从Session切换Token考虑的最核心原因是跨端和跨域。网页、小程序、App统一的登录凭证方案Token明显更省事。App端不需要处理Cookie存储请求头里加东西总比处理Cookie容器方便。第二个原因是分布式场景。Session方案在多节点部署下需要Redis集中存储Token方案天然适合无状态服务。JWT自带了身份信息和过期时间服务端只要验证签名不需要每次都查一遍缓存。但JWT也有它的坑最明显的是“过期时间难控制”和“Token膨胀”。有些项目不管接口数据量大小把一堆权限信息全塞进JWT结果每个请求光Header就好几KB又占带宽又影响性能。我个人的建议是JWT里只放用户核心标识和少量非敏感声明像权限明细这类易变数据该查库还是查库。另外“Token一定比Session好”是另一种八股错误。如果你的业务就是纯PC端网站、单机应用、后台管理系统用Session方案反而更简单直接技术选型永远是看场景不是追热门。5. 登录态安全防线HttpOnly、SameSite、CSRF5.1 一个属性就是一道防线安全问题的本质是攻击者想偷你的身份凭证或者想让你在不知情的情况下发起恶意请求。Cookie属性在底层提供了几道基础防线。先看XSS攻击下的凭证窃取问题。如果页面存在脚本注入漏洞攻击者可以执行任意JavaScript。此时如果Cookie没有HttpOnly一句document.cookie就能把Session ID直接送到攻击者手里。设置HttpOnly后浏览器禁止JavaScript访问该Cookie这条偷取路径就被堵上了。它不能阻止XSS攻击本身但能减少攻击者获得凭证的机会。再看CSRF攻击。CSRF的思路是你已经在bank.com登录了Cookie里带着认证凭证。攻击者给你发了一个链接打开后页面里嵌着一个指向bank.com/transfer?tohackeramount1000的请求。浏览器发起这个请求时会自动带上bank.com的Cookie服务端无从判断这个请求是“你本人点的”还是“第三方页面替你发的”。SameSite属性就是为了对付这个问题。把它设置成LaxHTTP请求中的GET、链接跳转还可以带Cookie但POST表单、fetch等跨站请求就不会带了。设置成Strict更严格但用户体验差因为从第三方站点点击外链进入本站时也会丢掉登录态用户体会就是“明明登录了怎么又变未登录了”。Lax是目前兼容性和安全性的折中选择。再说Secure这个属性要求Cookie只能通过HTTPS传输。它针对的是中间人攻击——攻击者在局域网上截获HTTP明文流量就能得到Cookie。加了Secure后在HTTP环境下浏览器不发送这条Cookie相当于把明文泄露的口子堵上。代价是本地纯HTTP调试时不方便开发环境需要特殊处理。5.2 Set-Cookie被禁止或丢失从哪几个方向排查开发中经常出现“后端明明设置了Set-Cookie但浏览器里就是没有这条Cookie”或者“Cookie有了但请求没带过去”的情况。我之前排查这类问题基本按下面顺序走第一步看响应头里有没有Set-Cookie。打开浏览器开发者工具切到Network找到登录接口查看Response Headers。如果没有Set-Cookie问题在后端代码或网关层。第二步确认Cookie是否成功保存。切换到Application面板里的Cookies找到对应域名看看有没有那条记录。如果没有多半是属性不合法。常见原因包括Cookie值里有未编码的分号或中文、Domain不匹配、Path不对、Max-Age填了负数或0、页面是HTTP但Cookie设置了Secure。第三步确认请求时是否带上了Cookie。查看业务接口的Request Headers里的Cookie字段。如果响应里已经有了Cookie但请求不带检查三级因素请求地址是否匹配Domain和Path范围是否跨域是否受到第三方Cookie限制。还有一个容易被忽略的点服务端返回多条Set-Cookie时浏览器可能只处理其中一部分。在分布式网关、SSO场景里尤其常见比如网关给了一个全局票据Cookie业务系统又给了一个Session Cookie两边领域或Path规则不一致时后面的覆盖掉前面的或者两条Cookie都失效。建议把跨域SSO的Cookie统一规划Domain、Path、统一命名规范避免互相打架。**“Set-Cookie字段被禁止设置”**是另一个高频问题。搜过这个报错的人会发现多数场景和边缘函数、CDN、浏览器扩展拦截有关。排查思路和上面类似先抓包确认响应头是否有值再检查上层是否有防火墙、WAF或浏览器插件把Set-Cookie拦截掉了。如果本地开着类似“禁用Cookie”的隐私插件也会出现这个现象可以先开无痕模式排查。5.3 SameSite默认策略收紧老项目访问为何突然失效这两年很多人发现老项目在Chrome里动不动就登录失效但用户并没有做任何操作。一个很重要的背景是Chrome已经开始逐步把未声明SameSite属性的Cookie按Lax来默认处理。以前老项目里没有设置SameSiteCookie都是默认同携带跨站请求也能带现在浏览器把它视为Lax很多跨站跳转或嵌入场景下的Cookie就不带了。打个比方A系统中内嵌了B系统的iframe页面B系统的登录态Cookie如果没设置“在跨站iframe里也允许携带”的策略以前只要能配合就带现在浏览器默认不让带。项目方拿到“用户登录后在第三方页面里仍然未登录”的反馈最后定位到的原因往往是这里。解决方案很直接给相关Cookie显式设置SameSiteNone并加上Secure。注意SameSiteNone必须同时配合Secure否则浏览器直接拒绝这条Cookie。这里面的取舍在于允许跨站携带Cookie等于承担了CSRF风险你要确认自己的业务场景确实需要跨站携带Cookie并且补充其他安全手段。完全不需要跨站带Cookie的业务不要为了图省事把所有Cookie都设置成None这是我踩过坑之后的体会。6. 实操经验与常见问题快速排查6.1 线上登录态频繁失效按这个顺序查我把这类问题的排查顺序写成一个清单能解决大多数“登录态时好时坏”的诡异情况第一看时钟。先问运维或看服务器是不是有多个实例之间时间不一致。Session和Cookie的过期时间都是时间戳比较如果服务器时间漂移会导致Cookie刚发出去就“已经过期”。第二看域名。用户访问的是www.example.com后端种Cookie时Domain写的是example.com一般没问题但如果用户访问的是www.example.com.cn、example.cn这种不同主域Cookie就种不上。第三看有效期。两边有效期不匹配时现象是“Cookie还在但Session已经没了”或反之。我习惯把Session的超时时间设置得比Cookie短一点让Session先失效而不是让浏览器还挂着一条永远无法通过校验的Cookie。第四看服务端日志。登录接口返回码是不是200业务接口有没有把“未登录”错误码吞掉很多前端把401拦截后统一跳登录页但如果后端返回的是200业务错误码前端就没跳用户就会一直卡在“看起来登录了但其实所有请求都失败”的状态。第五看浏览器清除策略。用户在清理“Cookie和网站数据”后登录态消失是正常现象这不是Bug。但产品上要想办法降低感知比如登录前在服务端种一条“匿名标识Cookie”识别用户是否曾经登录过再引导重新登录而不是一进页面就要求输密码。6.2 前后端联调时Cookie常见的几个坑联调时最经典的“后端说设了前端说没有”的激烈争论我经历过太多次。问题排查的核心是先在浏览器开发者工具里搞清楚Cookie到底在哪一步丢的。前端主动设置Cookie的代码长这样document.cookie token token ; Path/; Max-Age7200;这种写法只适合在页面同域、无特殊路径规则下使用。如果前端和后端域名不同前端即使设置了Cookie请求发到不同域名的后端时也不会带上。这时候需要后端在响应头里设置或者调整接口跨域配置允许携带凭证。在前后端分离模式下跨域问题更明显。使用axios时必须开启withCredentialsaxios.defaults.withCredentials true;如果用了fetch也要设置fetch(/api/user, { credentials: include });不加这个参数浏览器发起跨域请求时不会携带Cookie后端自然认为你未登录。同时后端CORS配置里不能简单写*需要显式允许指定来源并设置Access-Control-Allow-Credentials: true。这两个条件必须同时成立否则浏览器不会把跨域Cookie请求放行。这是联调阶段出现“接口测试工具能通、浏览器里不通”的最主要原因。还有个小坑联调时使用的代理工具、Mock平台、接口文档站点往往会用不同的域名。你在Postman里测试通过了不代表浏览器里的生产环境能通过。Cookie是域名绑定的只要域名不一致就得重新处理一遍登录逻辑。6.3 别把“Web Session”和“工具会话”搞混了日常开发的时候还有一个非常容易混淆的点很多工具、中间件会把它们的连接也叫做“Session”。比如数据库连接会话、SSH连接的Session、远程桌面会话、各种客户端软件的登录会话。它们和Web里的HttpSession完全是两套东西。有次我在排查问题时同事说“Session down了”我以为HttpSession挂了查了半天结果是他在说SSH工具连服务器断开了。这种称呼混乱在团队协作里挺耽误事的。所以碰到“Session失效”“Session连接断开”第一件事是先对齐语境你是在说Web登录态还是在说某个网络工具或服务的连接搜Java相关八股的时候“JSchSession is down”这类报错常被捞出来它是SSH连接库抛出来的和Web登录态八竿子打不着。它们只是都借用了“会话”这个词而已。否则你会陷入“HttpSession配置都没问题为什么还报session is down”的困惑里。6.4 最后分享一个调试习惯调试Cookie和Session问题时我几乎不依赖打印日志更习惯直接看浏览器的开发者工具。在Application面板的Cookies中能看到当前域名下所有Cookie的Name、Value、Domain、Path、Expires、HttpOnly、Secure、SameSite。遇到问题先在这看一眼基本能定位八成问题。如果发现Cookie一直没保存可以先把网页地址改成同样域名下的http://localhost再试试是否和Secure属性有关。如果发现请求带了Cookie但后端不认可以看后端拿到的Cookie请求头长什么样子检查是不是格式被网关或代理改了。另外调Cookie逻辑时建议用无痕窗口测试不要用自己日常用的浏览器档案。日常浏览器里存了很多历史Cookie很容易掩盖“其实是新Cookie没设置成功”的问题。无痕窗口每次开启都是干净的能让你看到最真实的请求行为。Cookie和Session这套机制讲起来不难但真正要做到线上不出问题需要把原理和细节结合起来知道HTTP无状态才能理解为什么需要登录态知道Cookie的管理范围才能处理跨域和域名问题知道Session的存储位置才能设计分布式方案知道安全属性的作用才能写出扛得住攻击的登录逻辑。每次遇到登录态相关的疑难杂症我都是按这个思路去拆解的希望这篇文章也能帮你少走一些弯路。