jQuery Ajax 请求在页面里该怎么组织

2013 年做前端时，只要页面上有搜索、列表刷新、局部提交，基本就会碰到 Ajax。jQuery 把发请求这件事做得简单了很多，但真正容易混乱的地方，其实是请求前后页面状态该怎么处理。

不要只想着“把数据拿回来”

很多初学者第一次写 Ajax，注意力都会集中在 success 回调里：请求回来了，拿数据，塞进页面，看起来就结束了。但真实页面里，至少还会有这些状态：

• 请求发出前要不要禁用按钮
• 请求过程中要不要给提示
• 请求失败后界面要怎么恢复

如果这些状态没有想清楚，页面逻辑很容易越来越散。

一条更完整的写法

$('#loadBtn').on('click', function () {
  $('.msg').text('正在加载...');

  $.ajax({
    url: '/api/list',
    type: 'GET',
    success: function (res) {
      $('#result').html(res.html);
      $('.msg').text('加载完成');
    },
    error: function () {
      $('.msg').text('加载失败，请稍后再试');
    }
  });
});

这段代码不复杂，但它已经包含了那个阶段最常见的页面节奏：触发、等待、返回、提示。

页面更新区域要尽量固定

Ajax 让人兴奋的地方是“不刷新页面就能更新内容”，但如果更新目标不固定，问题也会很快出现。今天这里改 .list，明天那里改 .panel，久了以后你会发现一条请求影响了太多页面角落。

更稳妥的方式是：每个请求尽量只负责一个明确区域，比如结果区、提示区或者表单区。职责清楚之后，后面维护就不会那么吃力。

错误处理别省略

2013 年很多演示代码只写成功分支，看起来很顺，但真正上线后最容易出问题的往往反而是超时、接口异常或者返回格式不对。哪怕先只给一个“请求失败”的提示，也比页面无声无息地停在那里强很多。

小结

jQuery Ajax 的难点不在 API 本身，而在于你是否把页面状态一起组织好了。把请求前、请求中、请求后的界面动作梳理清楚，Ajax 才会真正成为提升体验的工具，而不是新的混乱来源。