阿贾克斯避坑：别只会调接口
阿贾克斯避坑这件事，真正容易出问题的不是语法，而是请求时机、状态管理、错误兜底和后端约定。很多页面看着能跑，一到弱网、重复点击、登录过期、跨域切换就露馅。咱这篇不讲玄学，专门拆 Ajax 背后的逻辑。
先说结论：Ajax不是万能胶
阿贾克斯，也就是前端常说的 Ajax，本质是浏览器在不刷新整页的情况下，悄悄向服务器要数据。它解决的是“页面不用重载也能更新局部内容”，不是解决所有性能问题。坑通常出在一个误会：只要接口返回了，页面就算完成了。实际项目里，用户点了两次按钮、接口慢了3秒、token过期、后端字段临时改名，都会把这个误会戳破。
我看过不少后台系统，列表筛选用 Ajax，新增保存也用 Ajax，但没有 loading、没有防重复提交、没有异常提示。测试环境顺得很，上线后客服一天能收到几十条“点了没反应”。这不是 Ajax 难，是边界没想清楚。
坑一：只处理成功，不处理失败
很多新手代码只写 success，接口 200 就渲染，失败就安静地失败。真正靠谱的写法要分三层：网络失败、业务失败、权限失败。网络失败可能是断网或超时；业务失败可能是库存不足、参数不合法；权限失败常见于登录过期。
解决办法很朴素：约定统一返回格式，比如 code、message、data；前端统一拦截 401；每个操作按钮要有失败提示。别让用户猜页面是不是卡住了。一个“保存失败，请重试”比沉默强太多。
坑二：重复请求把数据写乱
Ajax 最大的便利，是用户不用等整页刷新；它最大的麻烦，也是用户可以连续操作。比如用户双击“提交订单”，如果前端不禁用按钮，后端也没有幂等处理，就可能创建两条记录。别觉得这种事少见，移动端网络抖动时特别容易出现。
前端至少做两件事：请求发出后按钮进入 loading，完成前不允许再次点击；对搜索框这类高频输入，用防抖，等用户停 300 到 500 毫秒再请求。后端则要用订单号、请求 ID 或唯一键兜底。只靠前端拦不住所有情况。
坑三：跨域和缓存别临场救火
本地能调通，线上跨域报错，是 Ajax 项目里最常见的尴尬。CORS 不是前端加个头就完事，关键配置在服务器。要明确允许的 origin、method、headers，带 cookie 时还得处理 credentials，不能随手写星号然后上线。
缓存也容易阴人。GET 请求可能被浏览器或代理缓存，尤其是老项目里查状态、查进度时，明明服务器变了，页面还拿到旧结果。对实时数据，要么后端给正确的 Cache-Control，要么前端加版本参数，但别把所有请求都粗暴加时间戳，那会浪费缓存价值。
收回来：把Ajax当流程设计
阿贾克斯避坑的核心，不是背 API，而是把一次请求当成完整流程：发起前能不能点，发起中怎么反馈，成功后更新哪里，失败后怎么恢复，重复请求怎么处理，权限变化怎么兜底。你把这条链路画清楚，代码自然稳。
真正成熟的 Ajax 页面，用户未必感知到它厉害，只会觉得顺、准、不会莫名其妙。这个评价比炫技值钱。
常见问题
- 阿贾克斯请求一定要用 jQuery 吗？
- 不用。老项目常用 $.ajax，新项目更多用 fetch 或 axios。关键不是库，而是统一处理超时、错误、鉴权和返回格式。
- Ajax接口返回200就算成功吗？
- 不一定。HTTP 200 只代表请求到达并有响应，业务是否成功要看后端约定的 code 或 status，比如库存不足也可能返回200但业务失败。
- 阿贾克斯避坑最先改哪里？
- 先改全局错误处理和重复提交。它们影响面最大，也最容易让用户直接感受到页面是否可靠。