Cookie存客户端、存键值对，Session存服务端、靠Session ID关联；Cookie易被篡改不安全，Session数据更安全但ID需防护；Cookie生命周期由浏览器控制，Session由服务端控制；Cookie适合存非敏感偏好，Session适合存敏感会话状态。
Session 和 Cookie 都是用来维持用户状态的机制，但它们存储位置、安全性、生命周期和使用方式有本质区别。简单说：Cookie 存在客户端（浏览器），Session 数据存在服务端，而 Cookie 通常只存一个 Session ID 来“认领”服务端的 Session。
存储位置与数据归属不同
Cookie 是服务器通过 Set-Cookie 响应头写入浏览器的一小段文本数据，后续每次请求浏览器都会自动带上（除非被禁用或过期）。它真正保存的是键值对，比如 user_id=abc123; expires=Wed, 01 Jan 2025 00:00:00 GMT。
Session 是服务器为每个用户创建的一块内存（或数据库/缓存）空间，用来保存用户相关数据（如登录状态、购物车内容）。它本身不直接传给浏览器，只靠 Cookie（或 URL 参数）里的 Session ID 来关联。
- 默认情况下，Flask 或 Django 的 session 依赖 cookie 中的
session_id查找服务端对应的数据 - 你可以在浏览器开发者工具的 Application → Cookies 里看到
sessionid这类字段，但它指向的完整数据其实在服务器上 - 如果禁用 Cookie，部分框架支持通过 URL 传递 Session ID（不推荐，不安全）
安全性与可控性差异明显
Cookie 默认可被前端 JavaScript 读取（除非设了 HttpOnly），也容易被用户手动修改。敏感信息（如权限等级、余额）绝不能直接存在 Cookie 里。
立即学习“Python免费学习笔记（深入）”；
Session 数据存在服务端，用户无法直接访问或篡改内容，更安全。但 Session ID 一旦泄露（比如被 XSS 窃取），攻击者就能冒充用户——所以要配合 Secure（仅 HTTPS）、HttpOnly、SameSite 等属性保护 Cookie。
- 设置
HttpOnly=True可防止 JS 读取 Session ID - 设置
Secure=True确保 Session ID 只在 HTTPS 下传输 - Session 过期时间由服务端控制（如 Flask 的
PERMANENT_SESSION_LIFETIME），比 Cookie 的 expires 更可靠
生命周期管理方式不同
Cookie 的过期由浏览器按 Expires 或 Max-Age 字段控制，关闭浏览器后仍可能保留（除非是会话级 Cookie）。
Session 的生命周期通常由服务端决定：可以设为“浏览器关闭即失效”，也可以固定时长（如 30 分钟无操作就销毁）。即使 Cookie 没过期，Session 在服务端被清理后，该 ID 就无效了。
- Flask 默认 Session 是“临时会话”，关闭浏览器即失效（底层依赖浏览器会话 Cookie）
- Django 默认 Session 有效期为 2 周，可通过
SESSION_COOKIE_AGE调整 - 主动登出时，应同时删除客户端 Cookie 并使服务端 Session 失效（如调用
session.flush()或删数据库记录）
典型使用场景对比
Cookie 更适合存轻量、非敏感、需要长期记住的偏好类信息：语言选择、主题模式、广告跟踪 ID。
Session 更适合存短期、敏感、需强一致性的业务状态：是否已登录、用户角色、临时表单数据、防重复提交的 token。
- 用户登录成功后，服务端生成 Session 并返回 Set-Cookie；后续请求靠这个 ID 拿到用户身份
- 购物车若要求未登录也能加商品，可用 Cookie 存临时 cart_id；登录后则合并到用户 Session 或数据库
- 验证码图片的随机字符串通常存在 Session 里，校验时比对，用完即删，避免暴露在前端
