CORS跨域有脚本吗？搞懂这件事，前端少踩一半坑！
说实话，我第一次听到“CORS跨域有脚本吗”这个问题的时候，脑子里也是懵的，啥意思？CORS还需要脚本？不是浏览器自己就搞定了吗？后来踩了几次坑，被后端同事怼了几回，我才算真正搞明白，今天咱就好好聊聊这个话题,顺便把那些绕来绕去的概念给它捋直了。
先说说CORS到底是个啥玩意儿
你知道吧，浏览器有个“同源策略”，就是说我这个网页在 a.com，我想去请求 b.com 的数据，浏览器默认是不允许的，为啥？安全呗！不然你随便打开一个恶意网站，它偷偷拿你的cookie去请求银行接口,那还得了？
所以CORS（Cross-Origin Resource Sharing，跨域资源共享）就出来了，它本质上是一套浏览器和后端服务器之间的协商机制，注意啊，关键点来了——CORS主要靠HTTP响应头来实现，不是靠你写什么前端脚本。
那有人就要问了：“CORS跨域有脚本吗？我看有人用JSONP啊，那不也是跨域吗？”
哎，这就要分清楚了，JSONP确实是用<script>标签来实现跨域的，但那是JSONP，不是CORS，CORS走的是另一条路——服务端设置响应头，Access-Control-Allow-Origin、Access-Control-Allow-Methods 这些。
CORS跨域到底需不需要写脚本？
答案是：前端基本不用为CORS写什么特殊脚本，但有些情况下你确实得在代码里做点配置。
我举个例子啊,假设你用fetch发请求：
fetch('https://api.b.com/data', {
method: 'GET',
credentials: 'include' // 带上cookie
})
这段代码本身不叫“CORS脚本”，它就是个普通的请求，真正决定能不能跨域的是后端有没有返回正确的CORS头，如果后端没配好，你前端写再多脚本也白搭，浏览器直接给你拦下来，控制台一片红,气得你想砸键盘。
有一种情况前端确实要“写脚本”——预检请求（Preflight），当你发送的是非简单请求（比如PUT、DELETE，或者带了自定义头），浏览器会自动先发一个OPTIONS请求去问后端：“兄弟，我能不能这么干？”这个OPTIONS请求就是浏览器自动发的，不用你手动写,所以你也不用专门写个脚本来处理它。
不过呢，如果你用axios这类库，有时候会看到别人在拦截器里配置 withCredentials 或者处理跨域错误，那也算是一种“脚本配置”，但严格来说不是CORS本身要求的,而是你业务需要的。
我踩过的那些坑
有一回我调一个接口，本地开发环境跑得好好的，一部署到测试环境就跨域报错，我当时就纳闷了：“CORS跨域有脚本吗？我前端没动啊！”后来一查，原来是Nginx配置里少了 add_header Access-Control-Allow-Origin 那一行，你说气不气？明明是运维的事儿,非得让我前端背锅。
还有一次更离谱，后端说：“我配了CORS啊，Access-Control-Allow-Origin: * 都加了，你还想怎样？”结果我一发带cookie的请求，又挂了，为啥？因为 和 credentials: include 不能共存！浏览器说了：“你要么别带cookie，要么就指定具体域名，别拿星号糊弄我。”你看,这玩意儿细节多得很。
那JSONP算不算CORS脚本？
不算！JSONP是另一个时代的产物，它利用的是<script>标签没有跨域限制这个特性，你写个函数，然后动态创建一个script标签，src指向跨域接口，接口返回 callback({data}) 这样的JS代码，浏览器执行它，你的函数就被调用了，这确实算“跨域脚本”,但它不是CORS。
所以如果有人问你“CORS跨域有脚本吗”，你可以很装逼地回一句：“CORS不靠脚本，靠响应头；JSONP才靠脚本，但那不是CORS。”是不是瞬间显得很专业？
别搞混了
- CORS：浏览器机制，靠服务端响应头,前端基本不用写特殊脚本。
- JSONP：靠
<script>标签，算跨域脚本,但不是CORS。 - 预检请求：浏览器自动发OPTIONS,不用你写脚本。
- 前端要做的：正确设置请求头（比如
credentials），处理错误,别瞎背锅。
好了，说了这么多，你应该明白了吧？CORS跨域这事儿，真不是靠前端写脚本能解决的，下次再有人问你“CORS跨域有脚本吗”，你就把这篇文章甩给他,保准他看完直呼内行。
有啥问题欢迎评论区唠嗑,我看到都会回！