本文目录导读：
CORS跨域你会吗？别慌，我当年也被它整得头皮发麻！
哎哟喂,说到这个CORS跨域啊，我真是一把辛酸泪！（此处应有叹气声） 相信不少前端小伙伴都跟我一样，第一次遇到那个红彤彤的报错时，整个人都是懵圈的——明明接口地址没错，参数也对，怎么就被浏览器拦了呢？简直就像你拿着钥匙去开门，结果门锁说“我不认识你”，你说气不气人？
初遇CORS：这什么鬼报错？
我还记得那是某个加班的深夜,我正美滋滋地调试着刚写好的前端页面，突然控制台蹦出一行刺眼的红字：“Access to XMLHttpRequest at 'http://api.example.com' from origin 'http://localhost:8080' has been blocked by CORS policy”。
当时我的表情就是：😳？？？啥玩意儿？CORS是啥？我代码明明没问题啊！后来才知道，原来这是浏览器的同源策略在作祟——只要协议、域名、端口任何一个不一样，浏览器就会默认“不信任”这个跨域请求，直接给你拦下来，合着我连自己调的接口都不能访问了？这也太霸道了吧！
CORS到底是个啥？咱唠明白
好啦,情绪发泄完，咱们正经聊聊，CORS全称是 Cross-Origin Resource Sharing（跨域资源共享） ，说白了就是浏览器给HTTP请求加的一道“安检”，它分两种请求模式：
简单请求：比如GET、POST且Content-Type是application/x-www-form-urlencoded这些，浏览器直接发请求，服务器返回Access-Control-Allow-Origin头就行。
预检请求：只要带上自定义请求头（比如Authorization）、或者Content-Type是application/json、又或者用了PUT/DELETE方法，浏览器就会先发一个OPTIONS请求探探路，服务器得回复“小伙子你可以过来”，然后才发真正的请求。
是不是听着就头大？我当时就是被这俩玩意搞蒙了，尤其是预检请求，服务器没处理OPTIONS，直接给我返回405，我愣是排查了两小时，最后发现后端小哥根本没写预检响应逻辑……哎，真的是“前端背锅，后端躺枪”！
怎么破？这些姿势你得会
后端开绿灯（最省事）
让后端在响应头加上：
Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Allow-Credentials: true // 如果带cookie就加这个
但注意哦,通配符不能配credentials，不然也会报错，这点贼坑！
用代理中转（开发利器）
比如前端用webpack的devServer.proxy，或者Nginx反向代理，让请求“欺骗”浏览器——浏览器看到的是同域请求，自然不拦截了，我经常用Vite的proxy，真香！
JSONP（老古董但有奇效）
只支持GET，动态创建script标签来加载数据，虽然有点“土”，但遇到GET请求的跨域场景还是能救急的。
心态崩了？稳住！咱总结几句掏心窝的话
其实啊,CORS跨域这玩意儿并不可怕，可怕的是你不懂原理瞎调试，我后来总结了一套“三步排查法”：
- 看报错信息：是简单请求还是预检失败的？如果带OPTIONS，先检查后端有没有处理OPTIONS。
- 看响应头：用浏览器开发者工具看
Access-Control-*字段是否齐全。 - 看credentials：如果请求带了cookie，后端必须返回具体的origin（不能用*）且
Allow-Credentials: true。
最后送大家一句我的血泪教训：“跨域问题，前端调半天，可能后端一行代码就搞定；后端调半天，可能前端少个代理就白搭。” 所以呀，前后端沟通比技术更重要，真的！
好了,今天就唠到这儿，你被CORS坑过吗？欢迎在评论区吐槽，让我知道你也不是一个人！下次遇到跨域，记得深呼吸，先喝口水，然后拿出这篇笔记看看，保准你心里有底多了！😉
（悄悄说：关注我，后续再写写HTTPS和HTTP混用那种更酸爽的报错~）