防止重复发送 Ajax 请求

要考虑并理解 success, complete, error, timeout 这些事件的区别，并注册正确的事件，一旦失误，功能将再也不可用；
不可避免地比普通流程要要多注册一个 complete 事件；
恢复状态的代码很容易和不相干的代码混合在一块儿；

推荐用主动查询状态的方式（A、B，jQuery 为例）或工具函数的方式（C、D）来去除重复操做，并提供一些例子做为参考：

A. 独占型提交
只容许同时存在一次提交操做，而且直到本次提交完成才能进行下一次提交。

module.submit = function() {
  if (this.promise_.state() === 'pending') {
    return
  }
  return this.promise_ = $.post('/api/save')
}

B. 贪婪型提交
无限制的提交，可是以最后一次操做为准；亦即须要尽快给出最后一次操做的反馈，而前面的操做结果并不重要。

module.submit = function() {
  if (this.promise_.state() === 'pending') {
    this.promise_.abort()
  }
  // todo
}

好比某些应用的条目中，有一些进行相似「喜欢」或「不喜欢」操做的二态按钮。若是按下后不当即给出反馈，用户的目光焦点就可能在那个按钮上停顿许久；若是按下时即时切换按钮的状态，再在程序上用 abort 来实现积极的提交，这样既能提升用户体验，还能下降服务器压力，皆大欢喜。

C. 节制型提交
不管提交如何频繁，任意两次有效提交的间隔时间一定会大于或等于某一时间间隔；即以必定频率提交。

module.submit = throttle(150, function() {
  // todo
})

若是客户发送每隔100毫秒发送过来10次请求，此模块将只接收其中6个（每一个在时间线上距离为150毫秒）进行处理。
这也是解决查询冲突的一种可选手段，好比以知乎草稿举例，仔细观察能够发现：
编辑器的 blur 事件会当即触发保存；
保存按钮的 click 事件也会当即触发保存；
可是存在一种状况会使这两个事件在数毫秒内连续发生——当焦点在编辑器内部，而且直接去点击保存按钮——这时用 throttle 来处理是可行的。
另外还有一些事件处理会很频繁地使用 throttle，如： resize、scroll、mousemove。

D. 懒惰型提交
任意两次提交的间隔时间，必须大于一个指定时间，才会促成有效提交；即不给休息不干活。

module.submit = debounce(150, function() {
  // todo
})

仍是以知乎草稿举例，当在编辑器内按下 ctrl + s 时，能够手动保存草稿；若是你连按，程序会表示不理解为何你要连按，只有等你放弃连按，它才会继续。

============
更多记忆中的例子

方式 C 和 方式 D 有时更加通用，好比这些状况：
游戏中你捡到一把威力强大的高速武器，为了防止你的子弹在屏幕上打成一条直线，能够 throttle 来控制频率；
在弹幕型游戏里，为了防止你把射击键夹住来进行无脑游戏，能够用 debounce 来控制频率；
在编译任务里，守护进程监视了某一文件夹里全部的文件（如任一文件的改变均可以触发从新编译，一次执行就须要2秒），但某种操做可以瞬间形成大量文件改变（如 git checkout），这时一个简单的 debounce 可使编译任务只执行一次。

而方式 C 甚至能够和方式 B 组合使用，好比自动完成组件（Google 首页的搜索就是）：
当用户快速输入文本时（特别是打字能手），能够 throttle keypress 事件处理函数，以指定时间间隔来提取文本域的值，而后当即进行新的查询；
当新的查询须要发送，但上一个查询还没返回结果时，能够 abort 未完成的查询，并当即发送新查询；

参考资料：http://www.qdfuns.com/notes/17755/d62094bd9972ddd957ca4da671a48ff0.html