要考慮并理解 success, complete, error, timeout 這些事件的區(qū)別，并注冊正確的事件，一旦失誤，功能將不再可用；

不可避免地比普通流程要要多注冊一個 complete 事件；

恢復(fù)狀態(tài)的代碼很容易和不相干的代碼混合在一起；

推薦用主動查詢狀態(tài)的方式（A、B，jQuery 為例）或工具函數(shù)的方式（C、D）來去除重復(fù)操作，并提供一些例子作為參考：

A. 獨占型提交

只允許同時存在一次提交操作，并且直到本次提交完成才能進行下一次提交。

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

B. 貪婪型提交

無限制的提交，但是以最后一次操作為準；亦即需要盡快給出最后一次操作的反饋，而前面的操作結(jié)果并不重要。

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

比如某些應(yīng)用的條目中，有一些進行類似「喜歡」或「不喜歡」操作的二態(tài)按鈕。如果按下后不立即給出反饋，用戶的目光焦點就可能在那個按鈕上停頓許久；如果按下時即時切換按鈕的狀態(tài)，再在程序上用 abort 來實現(xiàn)積極的提交，這樣既能提高用戶體驗，還能降低服務(wù)器壓力，皆大歡喜。

C. 節(jié)制型提交

無論提交如何頻繁，任意兩次有效提交的間隔時間必定會大于或等于某一時間間隔；即以一定頻率提交。

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

如果客戶發(fā)送每隔100毫秒發(fā)送過來10次請求，此模塊將只接收其中6個（每個在時間線上距離為150毫秒）進行處理。

這也是解決查詢沖突的一種可選手段，比如以知乎草稿舉例，仔細觀察可以發(fā)現(xiàn)：

編輯器的 blur 事件會立即觸發(fā)保存；

保存按鈕的 click 事件也會立即觸發(fā)保存；

但是存在一種情況會使這兩個事件在數(shù)毫秒內(nèi)連續(xù)發(fā)生——當焦點在編輯器內(nèi)部，并且直接去點擊保存按鈕——這時用 throttle 來處理是可行的。

另外還有一些事件處理會很頻繁地使用 throttle，如： resize、scroll、mousemove。

D. 懶惰型提交

任意兩次提交的間隔時間，必須大于一個指定時間，才會促成有效提交；即不給休息不干活。

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

還是以知乎草稿舉例，當在編輯器內(nèi)按下 ctrl + s 時，可以手動保存草稿；如果你連按，程序會表示不理解為什么你要連按，只有等你放棄連按，它才會繼續(xù)。

============

更多記憶中的例子

方式 C 和 方式 D 有時更加通用，比如這些情況：

游戲中你撿到一把威力強大的高速武器，為了防止你的子彈在屏幕上打成一條直線，可以 throttle 來控制頻率；