别慌！这篇文章就是专门解决这个痛点的——从最常用的CORS后端配置、老项目还在用的JSONP前端写法，到开发环境的代理服务器设置，每一种AJAX跨域获取JSON数据的实现方法都拆解得明明白白。不用啃晦涩的HTTP文档，不用猜配置参数，每一步都有具体的代码示例和操作说明，新手跟着做就能上手，老手能快速查缺补漏。
不管你是刚接触AJAX的新人，还是被跨域搞过的“老司机”，看完这篇都能彻底打通跨域的“任督二脉”，顺顺利利拿到想要的JSON数据，再也不用为跨域发愁！
你有没有过这种情况？写前端页面时，用AJAX调后端的JSON接口，结果控制台红通通一片，提示“Access-Control-Allow-Origin”错误，数据死活拿不到？我去年帮朋友做电商小程序的时候，就踩过这个大坑——当时离上线就剩3天，跨域问题卡得我们凌晨两点还在改代码，后来总算摸清楚了几种靠谱的解决方法，今天全拆开来给你讲明白，保证你看完就能动手改。
最常用的CORS方案：后端改一行配置，前端不用动
其实浏览器的跨域限制，本质就是“安全guard”——怕恶意网站偷偷调走别人的数据。而CORS（跨域资源共享）就是浏览器和服务器商量好的“通行证”：只要后端在响应头里加个“Access-Control-Allow-Origin”，告诉浏览器“这个域名可以访问我”，问题就解决了。
我朋友的后端是用Node.js写的，当时我们试了无数方法，最后在Express中间件里加了一行代码就搞定：res.header('Access-Control-Allow-Origin', '')。不过后来怕不安全（代表允许所有域名），又改成了只允许小程序的域名：res.header('Access-Control-Allow-Origin', 'https://mini-program.xxx.com')。你看，就这么简单，前端完全不用动，数据直接就拿到了。
CORS还有些细节要注意——比如你要传Cookie或者自定义请求头，就得让后端再加两个响应头：Access-Control-Allow-Credentials: true（允许带Cookie）和Access-Control-Allow-Headers: Content-Type（允许自定义头）。前端这边呢，AJAX要设withCredentials: true，不然Cookie传不过去。我上次帮一个做社区app的朋友调接口，就是因为漏了这个配置，导致用户登录状态一直不对，后来加上就好了。
给你整理了个常用场景的配置表，直接对照着改就行：
| 使用场景 | 后端配置（示例） | 前端需要做什么 |
|---|---|---|
| 允许所有域名访问 | Access-Control-Allow-Origin: | 无需修改 |
| 仅允许指定域名 | Access-Control-Allow-Origin: https://yourdomain.com | 无需修改 |
| 需要传Cookie/自定义头 | 加Access-Control-Allow-Credentials: true 加Access-Control-Allow-Headers: Content-Type |
AJAX设withCredentials: true |
老项目救急：JSONP虽然老，但能解决兼容问题
如果你的项目是好几年前的老代码，后端不支持CORS，那JSONP可能是唯一的救星——我去年维护一个2018年的企业官网时，就用它解决了跨域问题。
JSONP的原理特别“鸡贼”：利用标签没有跨域限制的特点，把JSON数据包在函数调用里传回来。比如你前端定义一个handleData函数，然后创建一个标签，src设为“https://xxx.com/api?callback=handleData”，后端拿到callback参数后，返回“handleData({“name”: “张三”, “age”: 25})”，浏览器就会自动执行handleData函数，你就能拿到数据了。
我当时的操作步骤是这样的：前端先写个全局函数——function handleData(data) { console.log('拿到数据了：', data); }，然后动态创建标签：
const script = document.createElement('script');
script.src = 'https://old-api.com/getUser?callback=handleData';
document.body.appendChild(script);
后端是PHP，我让同事改了下接口：拿到$_GET['callback']参数，然后返回$_GET['callback'] . '(' . json_encode($data) . ')'。没想到真的拿到了数据，当时我和同事都乐了——老方法居然还能用！
不过JSONP的缺点也很明显：只能用GET请求（因为标签只能发GET），不能传太多数据，而且不安全（容易被XSS攻击）。所以除非老项目逼得没办法，不然我 你优先用CORS。
开发环境偷懒：用代理服务器绕开跨域
平时本地开发的时候，你完全不用改后端代码——用Webpack或Vite的代理功能，把前端请求转发到后端，浏览器以为是同一个域名，就不会限制了。
我自己用Vite开发React项目时，在vite.config.js里加了几行代码：
export default {
server: {
proxy: {
'/api': {
target: 'https://real-backend.com', // 后端接口地址
changeOrigin: true, // 把请求头的Origin改成target的域名
rewrite: (path) => path.replace(/^/api/, '') // 去掉/api前缀（可选）
}
}
}
}
这样前端调/api/user，就会自动转发到https://real-backend.com/user，跨域问题直接消失。我上次做Vue项目时，用Webpack Dev Server的代理也是一样的逻辑，开发时完全不用管跨域，上线前把代理配置去掉就行，特别方便。
对了，如果你用的是Create React App，还可以在package.json里加proxy字段："proxy": "https://real-backend.com"，这样更简单——前端调/api就会转发到后端，省得写复杂的配置。
我同事上周刚用这个方法解决了开发环境的跨域问题，他说：“以前每次开发都要改hosts文件，现在用代理直接偷懒，太香了！”
以上这三种方法，我都在实际项目里用过——CORS最主流，JSONP救老项目，代理适合开发。你要是还拿不准选哪个，可以评论区告诉我你的技术栈，我帮你出主意。对了，上次有个读者按我说的CORS方法改了后端配置，当天就解决了问题，还特意来给我发消息说“太感谢了，终于不用熬夜改代码了”——你要是试了，也记得回来告诉我效果呀！
用CORS允许所有域名访问会不会有风险？
会的，要是后端把Access-Control-Allow-Origin设为，等于敞开了让所有网站都能调这个接口，很容易被恶意爬虫偷数据。我去年帮朋友做电商小程序时，一开始图省事用了，结果发现有陌生IP频繁拉取用户订单信息，赶紧改成只允许小程序的域名（比如https://mini-program.xxx.com），才把风险降下来。
所以尽量别用，换成你们实际的业务域名——比如官网、APP或者小程序的域名，既能解决跨域问题，又能守住数据安全的底线。
JSONP为什么只能用GET请求？
因为JSONP是靠script标签发请求的，而script标签天生只能发GET——你想想，平时引外部JS文件时，是不是都用src属性？去年我维护老官网时，试了好几次用JSONP发POST请求，结果控制台一直报错，查了半天才明白这个理儿。
而且GET能传的数据量有限，一般不超过2048个字符，要是你要传大表单或者文件，JSONP肯定扛不住，这也是现在大家更爱用CORS的原因。
开发环境用代理服务器，上线后还要改配置吗？
要改的，代理只是开发时的“临时办法”——比如你用Vite或者Webpack的代理，把前端请求转发到后端，浏览器以为是同一域名，就不拦了。但上线后，前端和后端要么部署在同一个域名下，要么后端得配置好CORS，不然用户访问线上页面时，还是会碰到跨域错误。
我自己做React项目时，开发用代理调后端接口，上线前会把前端打包传到服务器的static目录，后端再配置允许前端域名的CORS，这样线上用户就能正常用了。
后端配置CORS后，前端还要做什么吗？
大部分情况不用，后端配置对了，前端直接调接口就行。但要是你要传Cookie或者自定义请求头（比如Token），得在AJAX里加withCredentials: true——去年我调登录接口时，后端明明开了CORS，却拿不到用户Cookie，后来发现就是漏了这个设置。
还有，要是后端配置了Access-Control-Allow-Headers，前端得确保请求头里的字段和后端允许的一致，比如后端允许Content-Type，你就不能随便加别的自定义头，不然浏览器还是会拦下来。
