多子域名共享 Cookie 鉴权状态的关键在于统一设置 domain 为 .example.com、path 为 /，并配合 CORS credentials 配置与 SameSite 策略；开发时需避免 localhost 调试陷阱，推荐 SameSite=Lax 或 None+Secure，并辅以认证中心校验与登出广播机制增强健壮性。
多子域名共享 Cookie 鉴权状态的关键，不在于“绕过限制”，而在于正确利用浏览器对 Cookie 的 Domain 属性支持规则——只要所有子域共用同一个顶级域名（如 app.example.com、api.example.com、user.example.com），就能通过统一设置 Cookie 的 domain 为 .example.com 实现自动携带与识别。
统一设置 Cookie 的 Domain 和 Path
这是最基础也最关键的一步。后端在登录成功写入鉴权 Cookie（如 token 或 session_id）时，必须显式指定：
- domain 属性为 .example.com（注意开头的点），不能是 example.com、www.example.com 或空值；否则仅当前域名生效，无法被其他子域读取
- path 属性为 /，确保根路径及所有子路径请求都携带该 Cookie
- 若部署在 HTTPS 环境，secure 属性必须为 true；若需跨站请求携带（如 iframe 场景），还需设置 samesite=none，但此时 secure 为强制要求
前后端协同：CORS 与 credentials 配置
当子域名之间通过 AJAX 调用接口（如 app.example.com 调用 api.example.com 的用户信息接口），需满足以下条件才能让浏览器自动带上鉴权 Cookie：
- 后端响应头中必须包含：Access-Control-Allow-Origin: https://app.example.com（不可用 *）
- 后端响应头中必须包含：Access-Control-Allow-Credentials: true
- 前端 fetch 或 axios 请求中需设置：credentials: 'include'
避免常见配置陷阱
很多项目卡在这类细节上导致看似配置了却无效：
- 开发环境本地调试时，用 localhost 无法模拟 .example.com 的父子关系，建议统一使用例如 local.app.example.com 和 local.api.example.com 并配 host 映射
- Cookie 的 domain 值写成 example.com（无点）会导致子域不可见；写成 www.example.com 则只限该子域
- SameSite 默认为 Lax，跨站跳转（如从 docs.example.com 点链接到 user.example.com）时不会发送 Cookie；若需跳转即保持登录态，应设为 SameSite=Lax（推荐）或 SameSite=None; Secure（仅限 HTTPS）
- HttpOnly 应设为 true，防止 XSS 泄露 token，前端 JS 不需要直接读取该 Cookie，由浏览器自动附带即可
补充建议：配套机制增强健壮性
仅靠 Cookie 共享存在单点失效风险，可叠加轻量级兜底策略：
- 各子域页面加载时，主动向统一认证中心（如 auth.example.com）发起一个 CORS 请求校验登录态，返回用户基本信息并缓存至 localStorage（非敏感字段）
- 登出操作需广播通知：调用 auth.example.com/logout 接口清除主 Cookie，并向各已打开的子域窗口 postMessage 触发本地清理逻辑
- 对关键操作（如支付、修改密码）做二次 token 校验，不完全依赖 Cookie 自动携带
