“跨越了不同的域(名)想要去请求资源” 是有欠缺的，其实不只是域名，端口不同也算的。本质是因为同源策略，可以看看 https://zh.wikipedia.org/wiki/%E5%90%8C%E6%BA%90%E7%AD%96%E7%95%A5
你自己也没咋搞清楚嘛... 其实大多数前端在 cors 上踩坑都是因为下面这段： https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials 简单说就是带 cookies 或者其他什么 with credential 的请求，浏览器都默认发 "same-origin" 的请求。 而且就算你特意在 fetch() 里面设了 {credentials: "include"} ， 服务端的返回头里必须把 Access-Control-Allow-Origin 指定好特定的 origin, "*" 是不允许的会弹错 另外只要 cookie 的 "SameSite" 属性是"Lax"或"Strict"，也还是没法正常发 cookie 的 我敢打赌在座的各位前后端，必然都或多或少在这上面踩过坑。 谁要是确实第一遍看文档就注意到这里并且一次编码完成就再也没弹过错请大胆 at 我，受我一拜。
确实很多人不知道，可能还有另一部分原因，现在很多项目都是短平快，大家遇到问题总是希望有一个办法解决所有问题。不巧的是跨域这个问题很复杂，https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS 你没读 10 来遍是搞不清楚的。更悲剧的是，很多人都是看的二手资料，只知道了其中一部分，甚至是错的。 所以有了背 nginx 配置、jsonp 、Access-Control-Allow-Origin: * 等等片面的解决方案，毕竟具体问题具体分析很麻烦，反正这些都配置/用上，能跑就行
还有楼主说的 [浏览器会阻止给和页面地址不同的域名发请求] 其实也不完全是，就像前面说的，具体分析，有些请求是要等服务端返回，浏览器看一下 response header 才知道能不能跨域，这时候其实服务端已经处理成功返回了，只是返回的时候被浏览器拦截了。简单验证方法就是 Charles 抓个包，能看到 Charles 这边都是正常的。
