在互联网技术的世界里，Cookie 作为一种轻量级的客户端存储机制，早已成为 Web 开发中不可或缺的一部分，它不仅能够实现用户状态保持、个性化推荐等功能，还在提升用户体验方面发挥着重要作用，随着网站架构的日益复杂，特别是多域名、多子域名场景的普遍存在，Cookie 的作用域管理变得尤为关键。“父域名”与“子域名”的关系，直接决定了 Cookie 在不同域名间的共享与隔离，深刻影响着 Web 应用的功能设计与数据安全。
Cookie 的基本概念与作用域机制
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会携带在 HTTP 请求中，在浏览器与服务器间进行传递，其核心作用在于弥补 HTTP 协议无状态的缺陷，使得服务器能够识别用户身份、记录用户偏好，每个 Cookie 都包含一组属性，如名称（Name）、值（Value）、过期时间（Expires/Max-Age）、路径（Path）、域（Domain）、安全标志（Secure）和 HttpOnly 标志等，域”属性正是控制 Cookie 作用范围的核心。
默认情况下，Cookie 的作用域被限制在创建它的域名及其子域名内，在 www.example.com 下设置的 Cookie，默认情况下可以被 www.example.com 及其所有子域名（如 blog.example.com、store.example.com）访问，这种默认行为基于浏览器的同源策略（Same-Origin Policy），旨在平衡数据共享与安全隔离的需求，在实际开发中，我们常常需要更精细地控制 Cookie 的作用域，这就涉及到了“父域名”与“子域名”的显式配置。
父域名与子域名的定义及关系
在域名层级结构中，“父域名”是指直接包含子域名的上一级域名，对于 sub.example.com 而言，example.com 就是其父域名；而 sub 则是该父域名下的一个子域名，同样，blog.example.com 和 shop.example.com 共享同一个父域名 example.com，它们互为“兄弟子域名”。
Cookie 的域属性允许我们显式指定其作用范围，当在服务器端设置 Cookie 时，可以通过 Domain 属性指定一个父域名，从而实现该父域名下所有子域名共享 Cookie 的目的，若将 Cookie 的 Domain 属性设置为 .example.com（注意前面的点），则该 Cookie 不仅可被 example.com 访问，还可被其所有子域名（如 www.example.com、api.example.com、user.example.com 等）读取，这种机制在构建大型网站集群时尤为重要，它能够实现跨子域名的用户状态同步，例如单点登录（SSO）系统就需要依赖父域名 Cookie 来确保用户在多个子域名间的登录状态一致性。
子域名访问父域名 Cookie 的实现与注意事项
要让子域名能够访问父域名设置的 Cookie，关键在于设置 Cookie 时 Domain 属性的正确配置，当服务器在父域名（如 example.com）下设置 Cookie 时，若希望该 Cookie 对所有子域名生效，应将 Domain 属性显式设置为 .example.com，浏览器会将该 Cookie 的作用域扩展到该父域名及其所有子域名。
假设用户在 login.example.com 完成登录，服务器希望用户在后续访问 www.example.com 或 api.example.com 时保持登录状态，可以在登录响应中设置如下 Cookie：
Set-Cookie: sessionId=abc123; Domain=.example.com; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly这里的 Domain=.example.com 确保了 sessionId Cookie 可被 example.com 及其所有子域名访问，需要注意的是，Path 属性同样重要，它决定了 Cookie 在指定域名下的有效路径范围，通常设置为 以覆盖整个域名。
这种共享机制并非没有风险，由于父域名 Cookie 可被所有子域名访问，若某个子域名存在安全漏洞（如 XSS 攻击），攻击者可能窃取该 Cookie 并利用其访问其他子域名，从而危及整个系统的安全，在启用父域名共享 Cookie 时，必须确保所有子域名都具备足够的安全防护措施，例如设置 Secure 属性（仅通过 HTTPS 传输）、HttpOnly 属性（禁止 JavaScript 访问）以及采用 SameSite 属性（限制跨站请求携带 Cookie）等。
不同域名层级下的 Cookie 共享场景
为了更清晰地理解父域名与子域名 Cookie 的共享逻辑,我们可以通过以下表格对比不同配置下的作用范围：
| Cookie 设置的 Domain 属性 | 是否可被 example.com 访问 |
是否可被 www.example.com 访问 |
是否可被 blog.example.com 访问 |
是否可被 other.com 访问 |
|---|---|---|---|---|
| 未设置 Domain（默认） | 是 | 是 | 是 | 否 |
Domain=example.com |
是 | 是 | 是 | 否 |
Domain=.example.com |
是 | 是 | 是 | 否 |
Domain=www.example.com |
否 | 是 | 否 | 否 |
Domain=blog.example.com |
否 | 否 | 是 | 否 |
从上表可以看出，当 Domain 属性设置为 .example.com 时，其作用范围与 Domain=example.com 基本一致，但前者更符合浏览器对父域名匹配的通用规范，而若将 Domain 设置为具体的子域名（如 www.example.com），则该 Cookie 仅能被该子域名及其子子域名（如 sub.www.example.com）访问，无法被其他兄弟子域名（如 blog.example.com）共享。
总结与最佳实践
Cookie 的父域名与子域名机制是 Web 开发中实现跨域状态管理的重要工具，它能够在保证一定安全性的前提下，实现多子域名间的数据共享与用户状态同步，在实际应用中，开发者需要根据业务需求合理配置 Cookie 的作用域：若需要跨子域名共享（如单点登录、全局用户偏好），应将 Domain 设置为父域名（如 .example.com），并配合 Path=/ 确保全路径有效；若仅需在特定子域名内使用，则应将 Domain 设置为对应子域名,避免不必要的数据暴露。
安全性始终是 Cookie 管理的重中之重，无论采用何种作用域配置，都应启用 Secure 和 HttpOnly 属性，并结合 SameSite 属性防范 CSRF 攻击，对于敏感数据，应避免依赖 Cookie 存储，而是采用更安全的机制（如 Token 认证），通过精细化的作用域配置与严格的安全措施，我们既能充分发挥 Cookie 的便利性，又能有效降低潜在的安全风险，为构建安全、高效的 Web 应用奠定基础。
