I4.01.3debounce and throttle interval tradeoff设计
参数选择直接影响响应感与请求量
别名: 防抖等待 · 节流间隔 · debounce wait · throttle interval
概念解释
同一套「停稳再跑」或「按频率取样」的策略，等待和间隔取不同数字，人感到的快慢和系统接到的请求量会差出一个数量级。参数选择谈的就是这个数字：它同时改两件事——停顿之后还要再等多久才看到结果，以及一阵输入会触发多少次派生工作。策略选对了、数字抄错了，仍然会又慢又吵。
这条不重新定义两种策略各自干什么，只谈等待、间隔、以及「是否强制在某时限内必须开火」这些旋钮。
机制
trailing 等待叠在最后一次输入之后。人已经停手，界面还要再空等一个等待，再加上网络。等待过短，词内的正常间隙也会开火，请求量回到几乎每键一次，策略形同虚设；等待过长，整句已经在脑子里完成，屏幕上的建议还在原地，响应感掉在空等里，不在算法里。节流间隔过密，主线程和接口被均匀地打满，只是把尖峰摊成高原；间隔过疏，取样之间的画面或数值会跳，人把它读成卡，不是读成省了。
还有两个常被忽略的旋钮。一是 leading 还是 trailing：第一拍立刻跑能救响应感，但会用第一口不完整的值发一次请求。二是最长等待：有人连续输入超过数秒从不出现「停」，若没有上限，trailing 会一直憋着；有上限则保证再密的流也会定期落地，代价是中途值会被拿去执行。
边界
数字不能跨任务共用。搜索建议、窗口重排、滚动位置上报的可接受空等完全不同；把搜索上好用的等待搬到拖动预览上，拖动会呈一截一截。输入慢、用辅助技术逐字符输入时，短等待会把一次组词拆成多次查询，参数必须可被拉长或改为「失焦 / 确认」才执行。请求有计费、有写入副作用时，间隔的代价不是卡顿而是账单和重复写入，不能只按手感调短。实验室用自己的盲打速度调出来的值，对真实用户的停顿分布无效。
怎么落地
- 为每种派生工作单独记两个量：停顿后到首次可见结果的时延、一阵典型输入触发的请求或重算次数。两个一起看，不要只看其中一个。
- 用真实输入轨迹调，而不是从别处抄一个毫秒数。必要时加最长等待，避免连续输入永远不落地。
- 本地即时反馈不要算进这些参数里：字符必须当时出现；参数只约束请求和重排。
- 验证：用快速输入、慢速输入、中途停顿再继续三条轨迹。快速路径上请求应明显少于击键数，且停顿后结果在可接受空等内出现。把等待加到明显过长，建议应明显变晚；把等待加到接近零，请求应接近击键数。两条都要能复现，才说明参数真的在干活。