子域名间共享 Cookie 必须设 domain 为 '.example.com'，sameSite: 'None' 需与 secure: true 配对，前端 fetch 要 credentials: 'include'，后端 CORS 头需指定源并含 Access-Control-Allow-Credentials: true。
子域名间共享 Cookie 是常见需求，比如 app.example.com 和 api.example.com 需共用登录态，但必须严格遵循浏览器安全策略，否则 Cookie 会被拒绝或无法发送。
设置 domain 属性必须带前导点号
Cookie 的 domain 字段决定其作用域范围。要让主域及其所有子域都能访问，必须显式设为 .example.com（注意开头的点），而不是 example.com 或 www.example.com：
Cookies.set('token', 'abc', { domain: '.example.com', path: '/', secure: true, sameSite: 'None' })- 若写成
domain: 'example.com'，现代浏览器会将其视为仅限精确匹配，子域无法读取 - 若写成
domain: 'app.example.com'，则只在该子域生效，api.example.com无法获取
sameSite 和 secure 必须配对启用
当跨子域甚至跨完全不同的域名时，SameSite=None 是必需的，但它有硬性约束：
-
sameSite: 'None'必须与secure: true同时存在，否则 Chrome、Firefox 等主流浏览器直接忽略该 Cookie -
secure: true表示 Cookie 仅通过 HTTPS 传输，因此生产环境必须部署 HTTPS - 本地开发若用
http://localhost，可临时设secure: false，但上线前务必改回true
后端需配合 withCredentials 与 CORS 头
前端携带 Cookie 发起请求时，必须启用 credentials: 'include'，同时后端响应头必须严格匹配：
- 前端 fetch 示例：
fetch('https://api.example.com/login', { credentials: 'include' }) - 后端响应头不能写
Access-Control-Allow-Origin: *，而必须指定具体源，例如：Access-Control-Allow-Origin: https://app.example.com - 同时返回
Access-Control-Allow-Credentials: true，否则浏览器禁止将响应交给 JavaScript - 预检请求（OPTIONS）也需返回相同 CORS 头，且状态码建议为 204
避免敏感信息明文存储在 Cookie 中
即使配置正确，Cookie 本身仍是易受 XSS 攻击的载体：
- 不要在 Cookie 中存密码、原始 token 或用户完整信息；应使用短期、签名验证的 JWT 或服务端 session ID
- 添加
httpOnly: true（服务端设置）防止 JS 读取，降低 XSS 风险 - 搭配
maxAge或expires控制生命周期，避免长期有效凭证泄露 - 必要时结合 CSRF Token 双重校验，尤其在表单提交等操作中
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
