Session 和 Cookie 的工作原理核心是**"服务端存储+客户端标识"** 与 "客户端存储" 的差异，具体流程如下：
一、Session 的工作原理
Session 依赖"服务端存储会话数据+客户端携带会话标识"实现，流程分 4 步：
1.用户登录验证
- 用户输入账号密码发起登录请求，服务端验证身份通过后，创建一个专属的 Session 对象（存储用户信息、权限、登录时间等数据），并生成唯一的 Session ID（如一串随机字符串）。
2.传递 Session ID
- 服务端将 Session ID 写入一个 Cookie（通常名为 JSESSIONID 或 PHPSESSID），通过 HTTP 响应头发送给客户端浏览器。
3.客户端存储与携带
- 浏览器接收 Cookie 后，将其保存在本地（内存或硬盘）；后续用户访问该网站时，浏览器会自动在 HTTP 请求头中携带此 Cookie（含 Session ID）。
4.服务端确认身份
- 服务端接收请求后，从 Cookie 中提取 Session ID，通过该 ID 在服务端（内存、数据库、Redis 等）查询对应的 Session 对象，确认用户身份后返回对应内容。若查询不到 Session（如 Session 过期、ID 无效），则要求用户重新登录。
二、Cookie 的工作原理
Cookie 是服务端发送给客户端的"小型文本文件"，全程在客户端存储，流程分 3 步：
1.服务端生成 Cookie
- 服务端处理请求时（如用户登录、设置偏好），通过 HTTP 响应头的 Set-Cookie 字段，将需要存储的信息（如用户 ID、主题偏好）封装成 Cookie（可设置过期时间、域名、路径等属性），发送给客户端。
2.客户端存储 Cookie
- 浏览器接收后，按 Cookie 的属性（如过期时间）将其存储在本地（临时 Cookie 存内存，关闭浏览器失效；持久 Cookie 存硬盘，直到过期）。
3.客户端自动携带 Cookie
- 后续用户访问该 Cookie 对应的域名/路径时，浏览器会自动在 HTTP 请求头的 Cookie 字段中携带所有符合条件的 Cookie，服务端读取后即可获取客户端存储的信息（如确认用户身份、加载用户偏好）。
三、Session 的优缺点
优点
-
安全性较高：核心数据（如用户信息、权限）存储在服务端，客户端仅携带 Session ID，有效避免数据被篡改。
-
数据类型灵活：服务端存储 Session 时，可支持复杂数据类型（如对象、数组），不限于文本格式。
缺点
-
服务端压力大：每个用户会话都需占用服务端资源（如内存、数据库），高并发场景下易导致性能瓶颈。
-
扩展性差：分布式系统中，Session 需通过共享存储（如 Redis）同步，增加部署复杂度，否则用户跨节点访问会丢失会话。
-
依赖 Cookie：默认通过 Cookie 传递 Session ID，若用户禁用 Cookie，需通过 URL 重写等方式兼容，体验和安全性下降。
四、Cookie 的优缺点
优点
-
服务端无压力：数据存储在客户端，服务端无需额外存储资源，适合保存轻量信息（如用户偏好、登录状态标记）。
-
使用便捷：浏览器会自动在请求中携带 Cookie，无需开发者手动处理数据传递逻辑。
缺点
-
安全性低：数据明文或简单加密后存储在客户端，易被窃取（如 XSS 攻击）或篡改（如 CSRF 攻击），不适合存储敏感信息。
-
容量与格式限制：单条 Cookie 容量通常不超过 4KB，且仅支持文本格式，无法存储复杂数据。
-
跨域受限：默认遵循同源策略，无法在不同域名间共享，跨域场景下需额外配置（如 CORS），兼容性较差。
-
易被禁用：用户可在浏览器中手动禁用 Cookie，导致依赖 Cookie 的功能（如自动登录）失效。