从书城项目搞懂 Cookie 和 Session（附禁用 Cookie、对比 localStorage）

个人主页会编程的土豆欢迎来访作者简介后端学习者❄️个人专栏数据结构与算法数据库leetcode✨那些你一个人走过的夜路终将化作照亮未来的光最近在跟一个 Go 标准库写的网上书城net/http MySQL登录这块一开始挺懵一会儿 Cookie一会儿 Session文档还说“Session 存在服务器”。后来对着代码走了一遍才发现——说白了就是把登录信息放服务器这里是数据库表再给这包信息发一个 id把 id 塞进浏览器的 Cookie。下面按我自己的理解写清楚并结合这个项目里的真实写法1. 为什么需要它们HTTP 本身是“无状态”的你请求一次首页服务器处理完就结束了下一次请求过来它并不天然记得你是谁但商城必须记得你登录了没有购物车是谁的订单是谁的所以需要一种办法在多次请求之间把“用户身份”串起来常见方案就是Cookie Session2. 先用大白话说结论可以这么记登录成功后服务器把这次登录需要的信息比如user_id、username存起来——本项目存进 MySQL 的sessions表给这一行数据一个随机的session_id项目里用 UUID 生成把这个session_id通过 Cookie 发给浏览器保存Cookie 名字叫user。以后浏览器访问网站会自动带上这张 Cookie。服务器取出 Cookie 里的值sessionid当作 key 去sessions表里查出用户信息。所以Cookie 的 value ≈ Session 的 keysession_idSession 的内容 ≈ 这把钥匙对应的登录信息不是把整份用户资料都塞进 CookieCookie 里主要是一串 id3. Cookie 和 Session 分别是什么Cookie存在客户端浏览器本质是一小段“名 → 值”请求服务器时浏览器常会自动带上符合条件的 Cookie本项目登录成功后大致相当于告诉浏览器Cookie 名user Cookie 值一串 UUID也就是 session_id Path/Session存在服务端本项目里“在服务器”具体就是在数据库sessions表表里至少有session_id、username、user_id代码里的model.Session还带了Cart、Orders等字段那些多半是渲染页面时临时挂上去的方便模板取值真正登录时写进库的主要还是 id 和用户标识4. 结合书城完整流程4.1 登录时创建 Session并发 Cookie流程大概是用户提交用户名密码 →POST /login后端校验users表账号密码对不对生成 UUID 作为session_idinsert into sessions ...插入一行SetCookie把 UUID 放进名为user的 Cookie返回登录成功页对应到项目逻辑就是CreateUUID()生成 idAddSession(sess)写入数据库http.SetCookie(w, cookie)让浏览器存票可以把它想成把用户登录信息打包放进表里 → 给这包东西一个 id → 把 id 放到 Cookie 里4.2 登录后每次请求带着 Cookie 回来认人比如打开首页、加购物车、看订单浏览器会自动带上类似Cookie: userxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx后端常用IsLogin(r)这种逻辑r.Cookie(user)取出 Cookie用cookie.Value当session_idGetSession(session_id)查库查到且user_id 0→ 已登录拿到用户名、用户 id否则 → 未登录之后业务就能用session.UserID去查这个人的购物车、订单4.3 注销两边都清注销不能只清一边根据 Cookie 里的 value删除数据库sessions对应行DeleteSession再SetCookieMaxAge -1让浏览器删掉名为user的 CookiePath还要和登录时一致比如/再跳转回首页只删 Session 不删 Cookie浏览器还揣着作废号码只删 Cookie 不删 Session库里留着垃圾会话5. Cookie 和 Session 有什么区别系统对比两者都是跟踪用户状态的常用手段但差挺多存储位置Cookie客户端。请求时浏览器自动附带。Session服务端。服务器给每个会话一个 Session ID这个 ID 通常靠 Cookie或别的方式带回客户端。服务器再用 ID 找回 Session 数据。数据容量Cookie单个大概几 KB 量级浏览器还有个数限制。Session主要受服务器存储/内存限制理论上能放更多东西本项目放在 MySQL容量压力通常小于 Cookie。安全性Cookie在客户端相对更容易被盯上。可设HttpOnly降低被 JS 读取的风险本项目登录 Cookie 就用了HttpOnly但还要考虑 CSRF 等问题。Session敏感信息主要在服务端一般更稳妥但仍要防 Session 劫持别人偷到你的 Session ID、Session 固定等攻击。这也是为什么常见做法是Cookie 只放随机 id用户信息放 Session。生命周期Cookie可设过期时间也可做成关闭浏览器就失效的会话 Cookie。Session服务端可设超时一段时间没活动就过期。具体策略看实现本课设偏基础重点在“登录建、注销删”。性能Cookie每次请求都可能带上太大影响传输。Session服务端每次要根据 ID 查找查表/查缓存高并发时也有成本。6. 如果客户端禁用了 CookieSession 还能用吗默认情况下很多网站会不好使。原因很简单Session ID 默认常靠 Cookie 在浏览器和服务器之间传递。Cookie 被禁用后服务器没法方便地把 ID 存到浏览器浏览器后续请求也带不回这个 ID服务器就认不出“这是同一个会话”那是不是 Session 技术本身废了不是。只是传 ID 的通道断了。常见替代本课设没做了解即可方案一URL 重写把 Session ID 拼进每个链接例如http://example.com/page;jsessionidXXXX或作为查询参数。服务器从 URL 里解析 ID。缺点URL 难看链接被人转发时可能泄露 Session ID。方案二隐藏表单字段每个表单里藏一个隐藏域保存 Session ID提交时一起带走缺点只对“提交表单”友好普通点链接、很多 Ajax 还得额外处理所以实际项目里绝大多数还是能用 Cookie 传 Session ID 就用 Cookie7. 和 localStorage 比一比常被问有人会问那我干嘛不把登录信息丢localStorage区别大致是CookielocalStorage容量较小约 KB 级较大约 MB 级是否自动发给服务器会满足条件的请求自动带不会只在浏览器本地生命周期可设过期不主动删就一直在典型用途和服务器传身份凭证、会话 id同域页面间存前端数据、缓存什么数据更适合放哪更适合 Cookie需要跟服务器自动传递的、和会话相关的比如 Session ID需要过期控制的小数据。更适合 localStorage同域多页面共享的前端状态、体积更大的本地缓存不需要每次请求都自动上传的数据。回到登录这件事Session ID 放 Cookie 很合适因为每次请求都能自动带上服务器才能持续认出你。放 localStorage 的话你得自己用 JS 每次手动带还容易和纯前端存储混在一起也不是这门课设的路子。8. 结合本项目再强调三个容易混的点1“存在服务器”在这里 存在数据库表这个书城里不是神秘的内存黑盒就是sessions表keysession_idvalueusername、user_id等别的项目也可能用 Redis/内存那也叫服务端 Session实现可以不同思路类似。2Cookie 和 Session 不是二选一它们经常一起用Session 负责存“谁登录了”Cookie 负责把 Session ID 在浏览器和服务器之间传递3model.Session 字段看起来很多除了SessionID、UserName、UserID还有Cart、OrderID、Orders。后几个常常是页面渲染时临时挂上的方便模板一次性取出“欢迎谁 购物车/订单数据”不等于这些都长期写在 Cookie 里。9. 一张流程总图方便复习【未登录】 浏览器没有 user Cookie → IsLogin 失败 【登录成功】 校验账号密码 → sessions 表新增一行session_id 用户信息 → SetCookie(usersession_id) → 浏览器保存 Cookie 【之后每次请求】 浏览器自动带 Cookie: user... → 服务器用 value 查 sessions → 得到 user_id / username → 做加购、下单等业务 【注销】 DeleteSession(session_id) → SetCookie(MaxAge-1) 删浏览器 Cookie → 跳转首页10. 写在最后我自己是先被“服务器 Session、客户端 Cookie”绕住后来对着书城登录代码看明白的Session 像服务器上的一张表或一份映射Cookie 像浏览器里只保存钥匙的小票。钥匙对上了才知道你是谁钥匙扔了注销或者服务器把柜子清了删 Session登录态就断了。如果这篇文章帮你把这块串起来了建议再自己点一遍登录 → 看浏览器 Application 里的 Cookie → 再查数据库sessions表 → 再点退出对照两边是否一起消失。比只看文字扎实得多