在无法访问主域名（如 parent.com）的前提下，仅通过子域名（如 my-project.parent.com）无法实现与同级子域名（如 other-project.parent.com）的 cookie 共享，因为跨子域 cookie 必须由根域（.parent.com）显式设置并指定 domain 属性。
在无法访问主域名（如 parent.com）的前提下，仅通过子域名（如 my-project.parent.com）无法实现与同级子域名（如 other-project.parent.com）的 cookie 共享，因为跨子域 cookie 必须由根域（.parent.com）显式设置并指定 domain 属性。
Cookie 的作用域由浏览器依据 Domain 属性严格控制。若希望 cookie 在 my-project.parent.com 和 other-project.parent.com 之间共享，该 cookie 必须由服务端在响应头中设置为：
Set-Cookie: session_id=abc123; Domain=.parent.com; Path=/; HttpOnly; Secure
注意关键点：
-
Domain=.parent.com（开头的点号表示匹配所有子域）； - 此 header 只能由 parent.com 或其子域的服务端在响应中发出；
- 浏览器会拒绝前端 JavaScript（如
document.cookie）或fetch/XMLHttpRequest设置Domain属性——这是安全限制，不可绕过。
⚠️ 常见误区澄清：
- ❌ 在
my-project.parent.com中用document.cookie = "key=val; domain=.parent.com"无效（浏览器忽略 domain 设置）； - ❌ 使用
SameSite=None; Secure不能替代 Domain 控制，它仅影响第三方上下文发送行为； - ❌ CORS 配置、
withCredentials: true或代理转发均无法让 cookie 自动跨子域生效——cookie 域名匹配发生在请求发起前，与响应头无关。
✅ 可行替代方案（无需主域代码权限）：
-
后端代理中转：在
my-project.parent.com后端调用other-project.parent.com的 API，并由该后端统一处理认证/数据透传（如 JWT 或 session ID 作为请求参数）； -
URL 传参 + 短期令牌：生成带签名的一次性 token，重定向至
other-project.parent.com/?token=xxx，由其后端校验并建立本地会话； -
Shared Web Storage via postMessage（限同源窗口）：若两项目可通过 iframe 或弹窗交互（例如
my-project嵌入other-project的 iframe），可借助window.postMessage()安全传递数据，但需双方协作实现消息监听与验证。
总结：Cookie 跨子域共享本质是服务端能力，而非前端配置问题。若无法协调主域或同级子域的服务端共同设置 .parent.com 域 cookie，则必须放弃 Cookie 方案，转向无状态、显式传递的替代机制。
