HTTP 本身无状态：每个请求在协议层面独立；要在多次请求间识别「同一用户」或维持「登录态」，需要额外机制。 常见两种互补思路：把票据放在客户端 Cookie，或把会话数据放在服务端（Session），或二者组合。 理解它们的边界有助于正确实现注销、跨域与安全策略。
入门：Cookie 是什么
Cookie 是浏览器替服务器存储的一小段名字–值对（及若干属性），在后续符合条件的请求里自动带回（视 Domain/Path/SameSite/Secure/HttpOnly 等属性而定）。
它适合存放会话标识符（session id），而不是大块敏感业务数据——后者通常放服务端。
入门：Session 是什么
Session（服务端会话）：服务器为某次「登录会话」在内存、Redis、数据库等介质中保存结构化状态（用户 id、角色、购物车等）。 客户端往往只持有一个随机、难猜测的会话 id（常通过 Cookie 传递）；服务器用 id 查表得到完整状态。
深入：组合方式与安全要点
- Cookie + 服务端 Session：业界最常见；注销时删服务端会话并使 Cookie 失效。
- JWT 等自包含令牌：状态编码在令牌内，服务端无状态校验签名；刷新、吊销与密钥轮换策略更复杂，需单独设计。
- HttpOnly：缓解 XSS 窃取会话 Cookie；但不能替代输入校验与 CSP 等纵深防御。
- SameSite：缓解部分 CSRF；与「跨站打开登录页」体验存在张力，配置需读浏览器与框架文档。
常见误区
- 「Cookie = 不安全」：问题在于怎么设置与配合 HTTPS，而非 Cookie 本身。
- 「Session 存在服务端就一定更安全」：若会话 id 可预测或可固定，同样会被劫持。
精确属性语义与 SameSite 行为演进以各浏览器与 MDN 当前文档为准；合规场景（隐私法）还可能涉及同意横幅与第三方 Cookie 限制。