來自我的同事，sap成都研究院的架構師li ben。
但是有時候輸入abcde，會匹配更多的結果，發現裡面有些item並不匹配abcde，他們只能匹配abcd:
使用者輸入到abcd和abcde的時候，都向後台發出了請求查詢匹配的結果，最後將結果顯示到suggestion item中。
方法1 - throttle: 函式節流
throttle又叫函式節流，目標是防止短時間內對一些昂貴的函式做出重複呼叫。
實現思想是在第一次呼叫函式的時候做乙個定時器，同時設定乙個threshold時間(函式的真正邏輯在定時器的threshold時間之後才被定時器執行)，在該threshold之內，如果該函式沒有被再次呼叫，就讓定時器執行該函式的邏輯**；如果threshold之內該函式被再次呼叫，取消上一次設定的定時器，重新生成乙個新的定時器，讓真正的邏輯重新被推遲到threshold時間之後執行。例子:
方法2：asynchronous completion token(act):
act最早是用來解決通訊系統的多路訊號的問題，就是不同的請求發出之後，接受響應的一端需要知道每個響應對應的原始請求是什麼。我們live search的問題類似，我們需要知道匹配使用者最後輸入字串的那個響應，本質上也是act問題的一種。
act實現思路簡單講，就是給每個請求和對應的響應分配乙個唯一的token，響應返回的時候校驗token，具體實現結合應用場景可能有所不同。
我在my lead上為了驗證act簡單實現了一下：
(1) 定義兩個變數快取響應和使用者的最終輸入：
(2) 在change事件觸發的方法裡，讓slastinput保持跟使用者的輸入一致。
(3) 如果快取的響應裡面已經有了匹配的結果，不需要發出請求，直接從快取取，這裡我將使用者最終輸入的字串作為validate token。
(4) 如果快取裡面沒有匹配的結果才發出請求，在響應返回的callback裡面，快取結果並校驗token:
act pattern的更多介紹:
這本書裡也講了act：
比較一下throttle和async completion token:
函式節流和防抖
click scroll resize change這些事件會被頻繁觸發，如果改變了元素的位置，會引起回流和重繪，影響使用者體驗。對於優化這種現象，有節流和防抖兩種方案。函式防抖，通過 settimeout 和cleartimeout來實現，延遲執行函式。如果函式多次觸發，則把上次記錄的延遲執行 用...
函式防抖和函式節流
1 函式防抖 函式防抖是指頻繁觸發的情況下，只有足夠的時間，才執行 一次，函式防防抖的要點也是要乙個settimeout來輔助實現，延遲執行需要跑的 如果方法多次觸發，則把上次記錄的延遲執行 用cleartimeout清理掉，重新開始。如果計時完畢，沒有方法來訪問觸發。則執行 函式防抖的應用場景，最...
函式防抖和函式節流
首先分別用一句話區分函式防抖和節流的區別。函式防抖就是在使用者停下相應動作，並在給定時間過去之後僅被呼叫一次。函式節流是使用者在執行相應動作時，每隔一段時間發一次請求。針對一些頻繁觸發的事件如scroll keyup resize，如果正常繫結事件的話，可能在很短的時間內連續觸發事件，十分影響效能。...