本文内容主要翻译自issue 中国外大佬对防抖与节流的解释, 后面补充了自己的理解和总结。
什么是防抖与节流
防抖和节流是处理“过于频繁”发生的事情的常用技术。想象一下，你和朋友见面，朋友正在给你讲一个故事，但他们说话时很难停下来。假设您想在可能的情况下不打断他们满足他们讲故事的兴致，同时还要回应他们所说的话。 （我知道这可能有点做作，但请耐心等待！）
假设你们永远不能同时说话。你有几个策略：
同步
你可以在他们说完每句话时做出回应：
如果您的回复很短，这可能没问题。但是，如果您的回答较长，这可能会使他们很难讲完这个故事。所以这个策略不是很好。
防抖（Debounced）
你可以等他们停止说话。例如，如果他们停顿的时间足够长，您就可以开始回应：
如果你的朋友偶尔会停下来，这个策略会很有效。但是，如果他们不停地说了几分钟，这根本不会让你回应：
节流（Throttled）
您可以决定最多每分钟响应一次。在这里，您可以计算自己有多久没有说话了。一旦你一分钟没有说话，你就在朋友的下一句话之后插入你的回应：
如果您的朋友希望您在他们讲故事时做出回应，但他们不会为您做这件事而制造停顿，则此策略会很有帮助。但是，如果他们中间停顿了一会，但您仍在无缘无故地等待，此时双方都没说话，那就尴尬了：
含义解释
朋友的“句子”是按钮点击或键盘输入等事件。您的“回应”正在更新屏幕。
当用户做某事太快（例如打字）时，响应每个单独事件更新屏幕太慢。因此，您可以使用防抖或节流，要么等待用户停止输入（防抖），要么每隔一段时间更新一次屏幕，比如每秒一次（节流）。
补充举例
游戏中：防抖就是 B 回城，以按下的最后一下为准。节流就是 QWER，按一下再按得等技能冷却才能再按。
生活中：假设电梯有两种运行策略 防抖和 节流，超时设定为 15 秒，不考虑容量限制。
电梯第一个人进来后，15 秒后准时运送一次，这是节流
电梯第一个人进来后，等待 15 秒。如果过程中又有人进来，15 秒等待重新计时，直到 15 秒后开始运送，这是防抖
编程中：搜索页面,用户连续输入,等停下来再去触发搜索接口，这是防抖。
美团后台位置服务不能过于频繁地调用后台更新用户位置，必须以特定频率调用后端接口，这就是节流。
定义总结
防抖: n 秒后在执行该事件，若在 n 秒内被重复触发，则重新计时，所以防抖是操作时不执行不操作时执行。
节流: 高频事件触发，但在 n 秒内只会执行一次，所以节流会稀释函数的执行频率，到时候了必须执行一次。
图解说明
为什么防抖有 trailing 模式和 leading 模式?
原因：您可能会发现防抖事件在触发函数执行之前等待，直到事件停止如此迅速地发生，这让您感到恼火。（trailing edge 的情况），为什么不立即触发函数执行，使其表现得与原始的未防抖处理程序完全一样？于是就有了 leading edge 的情况。