做不做的答案其实很简单，就是你进行调整后，开发者是否还能还原原来的功能以及是否有必要。

比如说 onClick 防抖，那在不防抖的场景里（比如抢票、短时间点击抢积分等等）开发者就需要绕非常大的一圈来实现支持多点击效果。

那是不是可以加一个属性来支持配置？那就看你的库是否贴近底层，越近越受限制，越远越自由。一个 onClick 防抖需要在 Fiber 节点里存储最近点击数据（我们暂时不提 Fiber 本身是一个抽象节点，本来就不应该关心这件事），那对于大量不处理点击事件的节点都是没有意义的数据，但是因为冒泡以及可以存在动态调整 props 来支持 onClick ，导致框架层必须要预存数据。对于性能与内存都是没有必要的。

比如我要做个连点器或者计数器怎么办

防抖功能完全可以通过引用第三方包或者手动实现，通过高阶函数传参控制

防抖了
还要不要双击选中文本？
还要不要事件冒泡？
如果不要冒泡导致全局事件埋点失效怎么处理？
如果需要冒泡怎么既可以让事件冒泡又能实现防抖效果？
防抖有那么多配置项，防抖延时是前置还是后置？
既然都有防抖了要不要支持节流？

你觉得只是加个防抖，在框架作者看来需要处理一堆问题

框架设计需要考虑普遍的通用性，“防抖”可以说是业务层面的事情。

如果框架连这些内容都要事无巨细的处理，那么会背上沉重的技术债，而且也会丢失通用性。

很多人只嘲讽，不讲逻辑。我尝试讲讲看。

首先，从原教旨主义上讲，事件的触发默认逻辑就是多线程的。既触发几次事件，响应的方法就应该执行几次。所以至少不能默认“防抖”。

其次，“防抖按钮组件”是存在的。只是不是 React 提供的而已。

然后，“防抖按钮”在目前的互联网逻辑下用的多么？多。因为当今远程访问多了，延时大了，不防抖很容易和用户意愿相悖。

最后，React 应该给机制来解决么？不应该。因为 React 解决的，是也仅是“前端的职能管理与分工”问题。不解决业务与 UI 问题。

所以，不是 React 应该包含，而是你应该使用一个带 loading 按钮的 UI 组件库。

回答完毕。

btw:由此就引申出一个问题。目前多数新的 web 应用都上框架，是因为管理职能的需要。
使用框架并不是 web 开发的必要条件。

所以不要啥事儿都往 React 、Vue 、Angular 身上遮。

防抖不是刚需。

而且——
绝大部分在 onclick 事件上用防抖，是错误的。
防抖是给 oninput 、onmousemove 、onresize 这类高频事件用的。
你要防止重复的异步网络请求，应该是用 disabled 来禁用按钮，待请求成功后再解除禁用。
防抖并不能阻止重复的网络请求。

@AV1 "绝大部分在 onclick 事件上用防抖，是错误的。
防抖是给 oninput 、onmousemove 、onresize 这类高频事件用的。"

没懂，onclick 事件和以上的几个事件有什么区别？
只要是事件就有可能有防抖的业务需求，是否防抖跟是什么事件无关。防抖也不光指处理程序内部的逻辑噪声。

对应的，还有个处理方式叫“节流”。

另外，UI 上的反馈处理和事件上的防抖也并不冲突。UI 变化是人机工效逻辑（用于提示使用者的），事件防抖是业务逻辑（用来防止逻辑错误的）。

张三要防抖，李四说要节流，王五说要加延迟，赵六说要加立即执行，七七说要... 那么 React 就炸了。

所以 react 才有各种库...