了解浏览器 Cookie 行为（第2部分）

Source: Dev.to

介绍

在第 1 部分，我介绍了 cookie 是什么以及它们存在的原因。
在这篇第二篇文章中，我聚焦于一个在实际开发中常常引起困惑的话题：浏览器将 cookie 存储在哪里以及它们何时真正发送。

浏览器存储 Cookie 的位置

Cookie 会被浏览器自动存储和管理。具体的存储位置因浏览器而异，但原理相同。

• 通用：存储在本地 SQLite 数据库中（例如 Cookies 文件）。可通过 DevTools → Application > Cookies 查看。
• Safari（macOS / iOS）：由 WebKit 在内部管理，通常无法作为用户可见的文件访问。存储在 cookies.sqlite 中，并可通过 DevTools 的 Storage 选项卡查看。

在所有情况下，开发者都不会直接操作这些文件——浏览器会处理所有相关工作。

Source: …

当发送 Cookie 时

只有在 所有 必要条件都满足时，Cookie 才会被发送。如果有任何一个条件不满足，浏览器将不会包含该 Cookie。

Domain 属性

Set-Cookie: token=abc; Domain=example.com;

• 发送到 example.com、www.example.com 等。
• 如果指定 Domain=www.example.com，则 Cookie 只会发送到该精确主机。
• 若省略 Domain 属性，Cookie 将成为 仅主机 Cookie，只发送到签发域（不包括子域）。

Path 属性

Set-Cookie: token=abc; Path=/app;

• 仅在 /app 路径下的请求中发送。
• 使用 Path=/ 会导致 Cookie 在该域的 所有 请求中发送。

Secure 属性

带有 Secure 标志的 Cookie 仅在 HTTPS 上发送。

https://example.com   → 发送
http://localhost      → 不发送

这在本地开发中是一个常见的陷阱。

HttpOnly 属性

带有 HttpOnly 的 Cookie 不能被 JavaScript 访问。

document.cookie; // HttpOnly Cookie 不会出现

• HttpOnly Cookie 必须通过服务器的 Set-Cookie 响应头设置。
• 该属性对安全性至关重要，尤其是防御 XSS 攻击。

SameSite 属性

身份验证流程以及与外部服务的集成经常因 SameSite 规则而导致 Cookie 被阻止。现代浏览器严格执行这些规则；SameSite=None 必须配合 Secure 使用。

Safari的智能跟踪防护（ITP）

• 对第三方 Cookie 影响极大：会被非常快速地删除。
• 即使是第一方 Cookie，如果用户在 7 天内未再次访问，也可能被删除。
• 导致“登录会话突然失效”或外部集成不稳定。
• 通常遵循规范，但在隐私浏览模式下可能有所不同。

开发中常见的典型原因

• 同时存在具有不同 Path 值的 Cookie。
• 由于不同 Domain 设置导致创建多个 Cookie。
• 在跨站请求中，Cookie 被 SameSite 阻止。
• 在本地环境中，Secure Cookie 不会通过 HTTP 发送。
• HttpOnly Cookie 在 JavaScript 中不可见，导致困惑。
• 被 Safari 的 ITP 自动删除。

摘要

• Cookies 在浏览器内部存储（通常使用 SQLite）。
• 传输取决于 Domain、Path、Secure、SameSite 和 HttpOnly 属性。
• SameSite 是必须了解的关键现代属性。
• Safari 的 ITP 对 Cookie 行为影响很大。
• Cookie 持久化或消失的问题通常是配置或浏览器差异导致的。

接下来

在下一篇文章中，我将通过实际代码示例进行讲解，包括：

• 在服务器端（Java）发放 Cookie
• 使用 JavaScript 操作 Cookie
• 本地开发中的常见陷阱

Source: https://zenn.dev/bysontech/articles/68c9e472adb403

提示：为了帮助您完成翻译工作，请提供您希望翻译的日文原文内容（包括标题、正文、代码块说明等）。我将严格按照您的要求，只翻译文本部分，保持代码块、链接和 Markdown 格式不变，并将译文呈现为简体中文。谢谢！