使用 JavaScript 操作 Cookie 时，精准控制 domain 属性是实现跨子域名数据共享、用户状态同步以及构建单点登录（SSO）体系的核心技术手段。在开发过程中，正确设置 Cookie 的域名不仅关乎功能的实现，更直接影响到系统的安全性与用户体验。 许多开发者常常因为对域名匹配规则理解不深，导致 Cookie 无法在预期的域名下读取，或者引发安全隐患，本文将深入剖析 JS 指定域名 Cookie 的底层逻辑、匹配规则、安全策略及最佳实践方案。
核心语法与基础配置
在 JavaScript 中，设置 Cookie 的标准方法是通过 document.cookie 属性，这是一个可读写的字符串，但并非像普通变量那样直接赋值，而是需要按照特定的格式进行字符串拼接。要指定域名，必须使用 domain 参数。
基础语法结构如下：
document.cookie = "cookieName=cookieValue; domain=.example.com; path=/; expires=Thu, 01 Jan 2025 00:00:00 GMT; Secure";
在这个结构中,domain 参数决定了哪些主机可以访问该 Cookie，如果不显式指定 domain，默认情况下，Cookie 仅对当前所在的 Host（主机名）可见，在 app.example.com 下设置的 Cookie，默认只能在 app.example.com 下读取，无法被 www.example.com 或 api.example.com 访问。为了实现跨子域名共享，必须显式地将 domain 设置为主域名（如 .example.com）。
域名匹配规则与“前导点”机制
理解浏览器对 domain 的匹配规则是解决跨域问题的关键。RFC 6265 规范指出，若设置的 domain 值以点号（）开头，浏览器会将其视为“通配符域名”，允许该 Cookie 在当前主域名及其所有子域名下生效。
设置 domain=.example.com：
- 在
www.example.com下设置，该 Cookie 对blog.example.com、shop.example.com以及example.com均可见。 - 这种机制是实现企业级单点登录（SSO）的基础，用户只需在一个子系统登录，其认证 Token 即可流转至其他业务子系统。
如果不带前导点,即 domain=example.com，现代浏览器的行为通常与带点号一致，但为了兼容性和明确意图，强烈建议始终使用前导点（）来表示跨子域名的共享意图。
需要注意的是,你不能将 Cookie 的 domain 设置为当前页面的顶级域名之外的其他域名，在 a.com 下试图设置 domain=b.com 是会被浏览器严格禁止的，这是同源策略在 Cookie 机制上的重要体现，用于防止恶意网站篡改其他域名的用户数据。
安全属性配置与 SameSite 策略
在指定域名的同时,必须同步配置安全属性，以防止 XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）窃取用户凭证。
- HttpOnly 标志：虽然
HttpOnly无法通过 JavaScript 的document.cookie设置（它必须由服务器端在 Set-Cookie 响应头中指定），但在讨论 Cookie 安全时至关重要。它禁止客户端 JS 读取该 Cookie，即使攻击者注入了恶意脚本，也无法窃取带有HttpOnly的 Session ID。 - Secure 标志：带有
Secure标志的 Cookie 仅能通过 HTTPS 协议传输，在指定域名进行敏感操作（如登录态、支付信息）时，务必开启此标志，防止数据在传输过程中被中间人攻击截获。 - SameSite 属性：这是现代浏览器对抗 CSRF 的核心武器。
- Strict：最严格模式，Cookie 仅在第一方请求（即当前网站 URL 与 Cookie 所属域名一致）中发送，绝不随跨站请求发送。
- Lax：推荐模式，允许在顶级导航（如点击链接跳转）时发送 Cookie，但阻止图片、脚本、iframe 等第三方上下文中的 Cookie 发送。
- None：允许跨站发送，但必须同时配合
Secure属性使用。
在指定跨子域名 domain 时，通常建议将 SameSite 设置为 Lax 或 None（视业务是否需要跨站请求而定），以确保在主域名与子域名跳转时，用户状态能够正确携带。
常见问题与专业解决方案
在实际开发中,开发者常遇到“设置了 domain 却读不到”或“Cookie 丢失”的情况，以下是基于 E-E-A-T 原则的专业排查与解决方案：
Cookie 设置成功但在子域名下无法读取
- 原因分析：可能是
path（路径）属性限制过窄，Cookie 的作用域由domain和path共同决定，如果在domain=.example.com的同时设置了path=/app，/user路径下的页面将无法读取该 Cookie。 - 解决方案：对于需要全站共享的 Cookie，务必将
path设置为 ，确保覆盖站点根目录及所有子目录。
本地开发环境（localhost）无法模拟跨域
- 原因分析：浏览器对
localhost有特殊处理，且localhost不属于标准的域名层级，设置domain=.localhost往往无效。 - 解决方案：修改本地 hosts 文件，将
0.0.1映射为local.test.com和api.local.test.com等模拟域名，从而在本地环境真实复现跨子域名 Cookie 的交互逻辑。
Chrome 浏览器下第三方 Cookie 被阻断
- 原因分析：Chrome 正在逐步淘汰第三方 Cookie，如果你的业务架构涉及 A 域名嵌入 B 域名的 iframe，且希望 B 域名写入 A 域名的 Cookie，这将被视为第三方行为并被拦截。
- 解决方案：采用 Storage Access API 或重新设计架构，如果必须在 iframe 中交互，需请求用户授权；更优的方案是使用主域名作为统一认证中心，通过 URL 参数传递 Token 或使用 postMessage 进行跨域通信，而非依赖跨域 Cookie 写入。
相关问答
Q1：在 JavaScript 中设置 Cookie 时，domain 参数如果不带前导点（如 example.com 而不是 .example.com），会有什么后果？
A： 在大多数现代浏览器中，设置 domain=example.com 会被自动规范化为 .example.com，效果等同于带前导点，即包含主域名和所有子域名，为了确保在旧版浏览器（如旧版 IE）中的兼容性以及代码意图的清晰明确，最佳实践是始终显式添加前导点（.），这能确保开发者和维护者明确知晓该 Cookie 是设计用于跨子域名共享的，而非仅限于当前主机。
Q2：如何删除一个设置了特定 domain 的 Cookie？
A： 删除 Cookie 的原理是将其过期时间（expires）设置为过去的时间。关键点在于，删除 Cookie 时必须使用与设置时完全相同的 domain 和 path 参数，如果设置时使用了 domain=.example.com 和 path=/，但在删除时仅使用默认参数（即当前页面的 domain 和 path），浏览器将认为这是两个不同的 Cookie，从而导致删除失败，原 Cookie 依然存在。删除操作必须精准复刻创建时的作用域配置。
能帮助您彻底掌握 JavaScript 指定域名 Cookie 的应用技巧，如果您在项目中遇到了复杂的跨域认证难题，欢迎在评论区分享您的具体场景，我们可以共同探讨最优的架构方案。
