来自我的同事，SAP成都研究院的架构师Li Ben。
在SAP CRM Fiori App的早期开发过程中，关于live search功能上有一个问题，就是有时候发现live search返回的suggestion item并不完全匹配我们输入的search string, 比如正常情况输入abcde，应该匹配4个结果:
但是有时候输入abcde，会匹配更多的结果，发现里面有些item并不匹配abcde，他们只能匹配abcd:
问题分析
用户输入到abcd和abcde的时候，都向后台发出了请求查询匹配的结果，最后将结果显示到suggestion item中。
App请求的发送有先后顺序(先发abcd，再发abcde)，但是响应处理是通过异步回调，这里不能保证处理返回结果的先后顺序跟请求发送的顺序一致，在用户输入较快，或者后台处理需要一定时间的情况下，有可能第二个请求(abcde)先于第一个请求(abcd)返回。造成的结果是用户最后的输入停留在abcde，而最后的返回结果是匹配的abcd(如上图)。
改进方案
方法1 - Throttle: 函数节流
Throttle又叫函数节流，目标是防止短时间内对一些昂贵的函数做出重复调用。
实现思想是在第一次调用函数的时候做一个定时器，同时设定一个threshold时间(函数的真正逻辑在定时器的threshold时间之后才被定时器执行)，在该threshold之内，如果该函数没有被再次调用，就让定时器执行该函数的逻辑代码；如果threshold之内该函数被再次调用，取消上一次设定的定时器，重新生成一个新的定时器，让真正的逻辑重新被推迟到threshold时间之后执行。例子:
代码看上去还是很直观的。
Throttle - 函数节流的更多介绍：
http://wiki.jikexueyuan.com/project/brief-talk-js/function-throttling.html
方法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的更多介绍: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf
这本书里也讲了ACT：
http://software-pattern.org/Book/29
比较一下Throttle和Async Completion Token:
