同源策略（sop）是浏览器安全基石，非bug；它默认禁止跨源javascript读取dom、cookie、storage及ajax响应体，但允许跨源请求发送与资源嵌入。

浏览器的同源策略（Same-Origin Policy，SOP）不是 bug，而是安全基石：它默认禁止一个源（协议 + 域名 + 端口）的 JavaScript 脚本读取另一个源的资源，比如 DOM、Cookie 或 AJAX 响应体。关键点在于——限制的是“读取”，不是“发送”。请求能发出去，服务器也能正常响应，但浏览器在收到响应后会检查“有没有通行证”，没有就直接拦下，不交给 JS 处理。

同源策略到底拦什么？

它主要约束三类跨源交互：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 跨源 AJAX/Fetch 响应读取：脚本无法访问 response.text()、response.json()、response.headers 等，哪怕服务器返回了 200 和完整数据；
• 跨源 iframe 的 DOM 访问：父页不能用 document.getElementById('frame').contentDocument 拿到子页 DOM（除非双方主动配合如 postMessage）；
• 跨源 Cookie 和 Storage 访问：a.com 的脚本无法读取 b.com 设置的 Cookie、localStorage 或 sessionStorage。

CORS 是怎么“开绿灯”的？

CORS 不是绕过 SOP，而是 SOP 框架下的授权机制。它要求服务端在响应中明确声明：“我允许谁来读我”。浏览器收到响应后，只看几个关键响应头：

• Access-Control-Allow-Origin：必须匹配当前页面源（如 https://myapp.com），设为 * 表示任意源，但此时不能带凭证；
• Access-Control-Allow-Credentials：若前端 fetch 配了 credentials: 'include'（传 Cookie），此项必须为 true，且 Allow-Origin 不能是 *；
• Access-Control-Allow-Methods / -Headers：告诉浏览器“我接受哪些请求方法和自定义请求头”，尤其影响预检（OPTIONS）是否通过。

为什么有些跨域操作不报错？

因为 SOP 并非对所有跨源行为都拦截：

• 、<script>、<link></script> 加载资源可以跨域，但 JS 无法读取图片像素、脚本内容或样式表文本；
• 表单
  提交
  可以跨域跳转或提交，但 JS 拿不到响应结果；
• 简单请求（GET/POST + text/plain 等 Content-Type） 不触发预检，只要响应头合规，就能读取；
• 带 Authorization、application/json 或自定义 header 的请求 会先发 OPTIONS 预检，服务端必须正确响应预检，真实请求才被放行。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南