同源策略对cookie的隔离本质是防止恶意网站冒用用户身份，它不限制跨域请求发送，而是阻止浏览器自动携带cookie；只有协议、域名、端口完全一致才视为同源，跨域时需服务端明确返回access-control-allow-credentials: true及指定origin，并配合samesite=none与secure等cookie属性方可实现安全跨域携带。
同源策略对 Cookie 的隔离，本质是保护用户身份不被恶意网站冒用。它不是限制“跨域发请求”，而是阻止“跨域脚本读取或携带你的 Cookie”——哪怕请求发出去了，浏览器也不会把你的登录凭证自动塞进去，除非你和服务器都明确同意。
Cookie 自动携带机制本身不受同源策略禁止
浏览器在发请求时，会默认为同源地址附带对应域名的 Cookie。这是它的正常行为。但一旦目标地址跨域（协议、域名、端口任一不同），这个自动携带就会被拦截——不是因为技术做不到，而是同源策略主动掐断了这条通路。
- 例如：你在 bank.com 登录后，浏览器存了 session Cookie；此时访问 evil.com，它的 JS 尝试用 fetch 请求 bank.com/api/balance —— 请求能发出去，但浏览器不会带上 bank.com 的 Cookie
- 如果没这层隔离，evil.com 就能静默地用你的身份查余额、转账，完全无需你点击或输入
要让跨域请求携带 Cookie，必须前后端协同放行
仅靠前端设置 credentials: 'include' 是不够的，它只是“提出申请”。真正起决定作用的是服务端响应头是否允许：
- 服务端必须返回 Access-Control-Allow-Origin，且不能是通配符 *（必须写具体域名，如 https://app.example.com）
- 同时必须返回 Access-Control-Allow-Credentials: true
- Cookie 本身还得设好 SameSite=None 和 Secure（HTTPS 环境下才生效）
子域名间 Cookie 共享需额外配置
像 login.example.com 和 api.example.com 虽属同一主域，但仍被同源策略视为不同源。想共享 Cookie，得在设置时显式指定 domain=.example.com，让浏览器知道这个 Cookie 对整个域有效。
- 注意：domain=example.com（无点）只匹配该精确域名；domain=.example.com（开头带点）才覆盖所有子域
- 现代浏览器还强制要求 SameSite=Lax 或 Strict 为默认值，若要跨站发送，必须显式设为 None 并启用 Secure
同源策略不拦服务器，只拦“你的浏览器里的 JS”
很多人误以为 CORS 是“解决跨域”，其实它只是配合同源策略工作的协作机制。同源策略从不干涉服务器之间的通信，也不管后端怎么转发、代理、调用 API。它唯一约束的对象，是你当前页面里运行的 JavaScript —— 防止它偷偷用你的身份做坏事。
- 所以，用 Nginx 反向代理把接口变成同源，是绕过浏览器限制的常用做法，因为它让 JS 看起来是在和“自己人”通信
- 而 JSONP 已淘汰，正是因为它依赖 script 标签绕开 SOP，却无法控制响应内容，极易引发 XSS
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
