HTTP本来就不记事，可人要登录、要加购物车、要反复验证身份。这事儿明摆着矛盾——协议轻得像张纸，业务却重得要命。最近翻了不少资料，也试过自己写登录，才发现网上那些“Cookie是小纸条、Session是档案柜”的说法，越听越糊涂。
其实Cookie就是个快递信封。服务器塞进去一个sessionId或者一串token，浏览器乖乖收着，下次发请求时自动夹在信封里送回去。它自己不存密码，也不管你有没有登录，纯粹跑腿的。很多人把它当保险柜用，结果XSS一来，信封被偷，里面啥都没有也白搭。HttpOnly一关，JS就摸不着；Secure一设，非HTTPS不发；SameSite=Strict，跨站请求直接拦住——这些不是可选项，是底线。
Session才是真正在服务端记事的人。Tomcat一生成JSESSIONID，就把你的购物车、权限、登录时间全塞进内存或者Redis里。你刷新十次页面，它都认得你。但这东西太黏人了。一台机器挂了，session没了；加了负载均衡，不配Sticky Session，用户刚加完商品就变游客。还有，几千人同时在线，每个session占几KB，Redis内存蹭蹭涨。它没被淘汰，只是不声不响缩进银行后台、企业内网这些地方，只干最熟的活。
Token，尤其是JWT，走的是另一条路。它把该说的全写在客户端：谁发的、啥时候发的、到点作废。服务器拿到就验签名，对就放行，不对就拒。不用查数据库，不用连Redis，API网关扫一眼就能放行。但问题也在那儿——签发出去就收不回来。exp设成2小时，中间账号被盗，只能等它自己过期。所以现在大厂都搞短token+refresh token双机制，再加个Redis黑名单兜底。JWT也不是万能的，payload里塞用户角色可以，塞手机号？谁都能Base64解出来，等于贴脸喊。
对比下来，Cookie是管道，Session是账本，Token是带印章的证明。有人说“Cookie过时了”，可你用JWT，照样得靠Cookie传；有人说“Session太老土”，可银行转账点确认那一下，必须服务端秒杀会话。没有谁输谁赢，只有谁更合适。移动端用Authorization头传token，PC端用HttpOnly Cookie包着token，既防XSS又免手动带，这才是实打实的搭配。
最近在写个小程序后台，一开始全用JWT，结果登录态老断，查半天发现是token存在localStorage里，页面关了就丢。后来改存Cookie，加了Secure和SameSite=Strict，配合后端自动续期，稳定多了。另一个项目对接第三方，对方只认OAuth2，那JWT就是唯一选项，Session连门都进不去。
选哪个不看流行，看你在哪干活。做金融系统，Session加Redis集群最踏实；做开放平台，JWT是通行证；做个公司内部考勤，连Session都嫌重，Cookie配个简单token就够了。配置错了，再好的技术也白搭。HttpOnly漏了，XSS就能盗走一切；SameSite没设，CSRF就等着点链接；JWT用HS256却把密钥写进GitHub，等于把大门钥匙钉在公告栏上。
技术没高下，只有用错和用对。我试过把JWT payload写满用户信息，结果请求头大了一倍，Nginx直接502；也试过Session超时设成30天，结果用户电脑被借，别人刷了三天后台才发现。这些坑不是书里写的，是自己踩出来的。
写完登录，我关掉编辑器，泡了杯茶。
HTTP无状态，人有记忆。
信任不是天生的，是一行Set-Cookie、一次session.setAttribute、一次jwt.sign，一点一点敲出来的。
