I4.01.1debounce until idle设计
防抖延后执行直到输入停止
别名: 防抖 · debounce · 输入停稳再执行 · trailing debounce
概念解释
人在搜索框里连打十二个字母，系统不该发十二次查询。防抖（debounce）把执行推迟到输入流安静下来：每一次新事件都把计时器清零，只有空窗持续满设定等待之后，才用最后一次的值跑一次。它回答的是「这一串算写完了没有」，不是「写的过程中按多密的节奏取样」。
典型用在搜索即输入、自动补全、窗口尺寸停稳后再重排、地址联想。单次点击、一次提交，本来就没有串，不必套这层。
机制
击键不是均匀的泊松过程，而是一阵一阵：字母之间往往几十到两百毫秒，词与词、想词与打词之间会出现更长的缝。防抖把「缝长过等待」当成一阵结束的证据。代价是：真正的停顿之后，还要再空等一个等待，用户才看到根据整句算出来的结果。等待是在赌「下一次击键不会马上到来」——赌赢了，少做了大量中间态工作；赌输了，人会觉得搜得慢。
只处理最后一次，是因为中间态对这类任务通常无意义：「交互设」不是人想搜的，「交互设计」才是。本地的字面变化（插入字符、光标移动）必须立刻发生，防抖只绑在派生工作上：请求、重排、重算建议。把按键绘制也推迟，输入会变成在打空气。
边界
连续流没有「停」这个事件：滚动、拖动、跟手绘画，停下来才执行会让过程中完全没有取样，应当换策略。输入法拼写过程中，候选还在变，组字未上屏不算停稳，对拼音过程防抖会把半成品查出去。打字慢、用开关扫描、用语音断续输入的人，停顿结构不同于盲打，固定短等待会把一次词内犹豫当成结束，过早开火。只要每一次事件都有不可合并的语义（逐步撤销、逐步录音），防抖会吞掉必须留下的中间步。
怎么落地
- 把防抖接到搜索、过滤、建议、重排这类「只关心最终串」的派生工作上，不要接到按键绘制、按下态、字符插入。
- 用 trailing：停稳之后用最终值执行一次。需要「一开始就有反应」时，另给一层本地即时反馈，而不是改成一来事件就发请求。
- 对输入法：在组字结束（上屏）后再进入防抖，不要对 composition 中间态发查询。
- 验证：快速输入一个完整词，网络或重算应在停顿之后出现一次，而不是每个字母一次。把本地打字也推迟的实现判失败。用切换输入法拼一个词，确认未上屏时没有把拼音碎片查出去。