在一个典型的 SAP Fiori 搜索页面里，操作人员正在输入物料编号。输入M时触发一次事件，紧接着输入MA、MAT、MAT1。如果每次键盘输入都立刻调用一次 OData 服务，浏览器可能在极短时间里连续向 ABAP 后端发出多次 HTTP 请求，而真正有业务价值的往往只是操作人员停止输入之后的那个MAT1。这正是 RxJSdebounce和debounceTime最擅长处理的问题。RxJS 官方对debounceTime的描述非常明确。源Observable产生一个值之后，它不会马上把这个值传递给下游，而是等待指定的静默时间。如果等待期间又有新的值出现，前一个尚未发出的值会被丢弃，计时重新开始。只有连续一段时间没有新值到来，最新那个值才会真正发出。放到上面的输入过程里，可以理解成M到达，开始等待300 msMA很快到达，放弃M，重新等待300 msMAT到达，放弃MA，重新等待300 msMAT1到达，放弃MAT，重新等待300 ms后续300 ms ABAP 里有没有 RxJS 的 debounce，答案要从事件模型而不是关键字里找
在一个典型的 SAP Fiori 搜索页面里，操作人员正在输入物料编号。输入M时触发一次事件，紧接着输入MA、MAT、MAT1。如果每次键盘输入都立刻调用一次 OData 服务，浏览器可能在极短时间里连续向 ABAP 后端发出多次 HTTP 请求，而真正有业务价值的往往只是操作人员停止输入之后的那个MAT1。这正是 RxJSdebounce和debounceTime最擅长处理的问题。RxJS 官方对debounceTime的描述非常明确。源Observable产生一个值之后，它不会马上把这个值传递给下游，而是等待指定的静默时间。如果等待期间又有新的值出现，前一个尚未发出的值会被丢弃，计时重新开始。只有连续一段时间没有新值到来，最新那个值才会真正发出。放到上面的输入过程里，可以理解成M到达，开始等待300 msMA很快到达，放弃M，重新等待300 msMAT到达，放弃MA，重新等待300 msMAT1到达，放弃MAT，重新等待300 ms后续300 ms