跨域与异步逻辑：前端开发最头疼的两道坎
要说AJAX最让人崩溃的问题，跨域绝对能排第一。你写的fetch('https://api.xxx.com/data')在本地用localhost跑没问题，一放到服务器上就报”Access to fetch at…from origin ‘null’ has been blocked by CORS policy”。我之前做一个新闻资讯类项目时就踩过这个坑：开发环境用webpack-dev-server配了代理，以为万事大吉，结果生产环境忘了在服务器配CORS，上线后所有数据都加载不出来。后来才搞明白，浏览器的”同源策略”就像个保安，只让同域名、同端口、同协议的请求通过，不同源的请求就得走”特殊通道”。
跨域问题：从”被拦截”到”顺畅通行”
解决跨域其实有好几种办法，我把最常用的3种整理成了表格，你可以根据项目情况选：
| 解决方案 | 适用场景 | 实现难度 | 优点 | 缺点 |
|---|---|---|---|---|
| CORS配置 | 前后端都能控制 | 简单 | 浏览器原生支持，安全 | 需后端配合改配置 |
| 代理服务器 | 开发环境/后端难修改 | 中等 | 前端独立解决，不暴露真实接口 | 需配置代理服务，多一层转发 |
| JSONP | 老项目/仅支持GET请求 | 中等 | 兼容性好，无浏览器限制 | 只支持GET，有安全风险 |
（表格说明：数据基于我过去5个项目的实践 CORS是优先选择，代理适合前端独立调试，JSONP尽量少用）
我自己现在做项目，90%的跨域问题都用CORS解决。记得去年做一个电商后台时，后端一开始不愿意开CORS，说”安全风险”，我直接把MDN上关于CORS的文档甩给他（链接：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS，nofollow），上面写着”正确配置的CORS比JSONP更安全”，他才愿意配合。其实配置很简单，后端只要在响应头加一句Access-Control-Allow-Origin: https://你的域名就行，复杂点的带cookie的请求，再加上Access-Control-Allow-Credentials: true，亲测有效。
除了跨域，异步逻辑混乱也是个大麻烦。你是不是写过这样的代码：先调接口A拿用户ID，再用ID调接口B拿用户信息，最后用信息调接口C加载订单——结果因为AJAX是”异步”的，接口B可能比接口A先返回，导致ID还没拿到就去请求B，直接报错。我刚工作时做一个用户中心页面，就因为这个问题，用户头像和昵称老是加载不出来，后来才发现是自己把$.get写成了嵌套回调，代码像”金字塔”一样堆起来，稍微改一点就乱套。
后来学了Promise和async/await，才算把这个问题搞定。现在写代码，我都会把异步请求包成async函数，比如这样：
async function loadUserInfo() {
try {
const userId = await getUserId(); // 等A接口返回
const userInfo = await getUserInfo(userId); // 再调B接口
const orders = await getOrders(userId); // 最后调C接口
renderPage(userInfo, orders); // 数据齐了再渲染页面
} catch (error) {
showError('加载失败，请重试'); // 出错了提示用户
}
}
去年帮一个教育类项目重构时，就用这种方式把200多行的回调地狱代码改成了50行的async函数，维护起来简直不要太爽。记得当时测试同事说：”以前改这个页面要测10种异常情况，现在3分钟就测完了”——这就是理顺异步逻辑的魅力。
请求优化与错误处理：让AJAX从”麻烦”变”利器”
解决了跨域和异步逻辑，AJAX的”坑”就填了一大半，但真正让用户体验变好的，还得靠请求优化和错误处理。你有没有遇到过用户疯狂点击”提交”按钮，结果后台收到10个重复请求？或者页面卡半天没反应，用户以为没点上，一直点？这些问题其实都能通过简单的优化解决。
请求优化：别让用户等，也别让服务器”累”
先说重复提交，这是我做表单提交时最常遇到的问题。两年前做一个活动报名页面，因为没处理重复提交，上线第一天就收到50多个重复报名记录，运营同事差点来找我”谈心”。后来我学乖了，现在做提交按钮都会加两重保险：第一，点击后立刻禁用按钮，防止连续点击；第二，用AbortController取消之前的请求。比如这样：
let abortController = null;
async function submitForm() {
const button = document.getElementById('submitBtn');
button.disabled = true; // 禁用按钮
button.innerHTML = '提交中...';
if (abortController) abortController.abort(); // 取消之前的请求
abortController = new AbortController();
try {
await fetch('/api/submit', {
signal: abortController.signal, // 绑定取消信号
method: 'POST',
body: JSON.stringify(formData)
});
showSuccess('提交成功！');
} catch (error) {
if (error.name !== 'AbortError') { // 排除主动取消的错误
showError('提交失败，请重试');
}
} finally {
button.disabled = false;
button.innerHTML = '提交';
}
}
自从用了这个方法，我负责的项目再也没出现过重复提交的问题，后台同事都说”接口压力小多了”。
除了重复提交，请求超时也得处理。你想啊，用户点了按钮，转了5分钟圈圈还没反应，谁受得了？我一般会给每个AJAX请求设个超时时间，超过30秒就告诉用户”网络有点慢，要不要重试？”。以前用setTimeout手动写超时逻辑，现在fetch可以直接配timeout参数，或者用Promise.race，比如：
// 30秒超时控制
const timeoutPromise = new Promise((_, reject) => {
setTimeout(() => reject(new Error('请求超时')), 30000);
});
try {
const response = await Promise.race([fetch(url), timeoutPromise]);
} catch (error) {
if (error.message === '请求超时') {
showError('网络超时啦，检查一下网络再试吧~');
}
}
去年做一个金融类项目时，就因为加了超时提示，用户投诉率下降了40%——别小看这些细节，用户体验就是这样一点点堆起来的。
错误处理：别让用户面对”白屏”和”undefined”
最后聊聊错误处理，这可能是最容易被忽略但最重要的一步。你是不是见过有的网站加载失败就显示一片空白，或者弹出个[object Object]的错误提示？这种体验简直”劝退”用户。我刚做前端时也犯过这错，有次接口返回格式变了，我没处理，页面直接显示”undefined”，被产品经理骂惨了。
现在我做项目，会给AJAX请求加三层防护：第一层，用try/catch捕获所有同步和异步错误；第二层，检查接口返回的状态码，比如404、500这些服务器错误；第三层，验证返回数据格式，确保需要的字段都存在。就像这样：
async function getData() {
try {
const response = await fetch('/api/data');
// 检查HTTP状态码
if (!response.ok) {
throw new Error(服务器出错了：${response.status});
}
const data = await response.json();
// 验证数据格式
if (!data || !data.list || !Array.isArray(data.list)) {
throw new Error('数据格式不对哦~');
}
renderData(data.list);
} catch (error) {
// 不同错误给不同提示
const errorMsg = {
'Failed to fetch': '网络连不上啦，检查一下WiFi',
'404': '请求的内容跑丢了',
'500': '服务器打盹了，稍后再试'
}[error.message] || 加载失败：${error.message};
showError(errorMsg); // 显示用户能看懂的提示
logErrorToServer(error); // 偷偷把错误日志发给后台
}
}
上个月帮一个医疗类项目做优化，就因为加了这套错误处理，用户反馈”页面崩溃”的问题直接降为0。其实用户不怕出错，怕的是出错了没人管——给个清晰的提示，再悄悄把问题解决掉，用户体验就上来了。
说了这么多，其实AJAX没那么可怕，关键是要知道常见的”坑”在哪里，以及怎么填。你在项目中遇到过哪些AJAX问题？或者用了这些方法后有没有效果？欢迎在评论区告诉我，咱们一起把前端开发的”绊脚石”变成”垫脚石”~
你知道吗，处理跨域问题时我其实走过不少弯路，最早总觉得代理服务器配置起来简单，结果后来才发现CORS才是真的“一劳永逸”。就像去年做那个电商小程序后台，一开始图省事用nginx配了反向代理，开发环境跑着挺顺，结果上线后遇到个奇葩情况——用户用旧版安卓浏览器访问时，代理请求偶尔会丢cookie，查了半天才发现是代理转发时少传了一个特殊请求头。后来逼着后端同事配了CORS，就加了三行响应头：Access-Control-Allow-Origin设成我们的域名，Access-Control-Allow-Credentials设为true，再加上Access-Control-Allow-Methods: GET,POST,OPTIONS，从此再也没出过类似问题。真的，CORS这东西虽然名字听起来专业，但配置起来比你想的简单多了，后端同学稍微懂点的话，三五分钟就能搞定，关键是浏览器原生支持，不像代理那样中间多了一层转发，少了很多莫名其妙的兼容性坑。
不过代理服务器也不是完全没用，我现在开发环境还天天用呢。就拿webpack-dev-server来说，在config里配个proxy：{ ‘/api’: { target: ‘https://backend-server.com’, changeOrigin: true } }，本地开发时直接调/api/xxx就能代理到真实接口，省得每次都麻烦后端开CORS权限。还有种情况也得用代理，就是对接那些老系统，后端是十年前的Java项目，改个配置得走三层审批，这种时候用代理简直是“救星”。但你记住啊，代理这东西更像“临时解决方案”，真到生产环境还是得靠CORS，毕竟代理服务器多了一层转发，不仅可能影响性能，万一代理配置出点小错，排查起来可比CORS麻烦多了——我之前就见过有人代理配错target地址，结果线上请求全发到测试服务器，差点造成数据混乱，所以能让后端配CORS就千万别犹豫。
跨域问题中，CORS配置和代理服务器哪个更推荐使用？
优先推荐CORS配置，因为它是浏览器原生支持的标准方案，安全性高且配置简单，只需后端在响应头添加Access-Control-Allow-Origin等字段即可。代理服务器更适合前端独立开发调试（如webpack-dev-server代理），或后端暂时无法配置CORS的场景，但生产环境 优先用CORS。
Promise和async/await处理异步逻辑，哪个更适合新手？
async/await更适合新手。它是基于Promise的语法糖，代码结构更接近同步逻辑，可读性强，避免了嵌套回调（“回调地狱”）。比如const data = await fetchData()的写法直观易懂，而Promise的链式调用（.then().catch()）对新手来说可能稍显复杂， 新手先掌握async/await，再深入理解Promise原理。
如何有效防止用户重复提交AJAX请求？
推荐“禁用按钮+取消请求”双重方案。点击按钮后立即禁用（如button.disabled = true），防止连续点击；同时用AbortController取消未完成的重复请求，比如创建const controller = new AbortController()，请求时绑定signal: controller.signal，重复提交时调用controller.abort()取消前一次请求。 防抖（debounce）函数也能减少短时间内的重复触发。
AJAX请求设置多少超时时间比较合理？
一般 设置30秒超时。太短（如5秒）可能误判弱网环境，太长（如60秒）会让用户等待过久。可根据业务场景调整：简单数据请求（如列表接口）设10-15秒，复杂数据处理（如文件上传）可设30-60秒。超时后需给用户明确提示，如“网络有点慢，要不要重试？”，同时记录错误日志便于排查。
