在 React 中，onChange 和 onInput 之间有什么区别？

似乎没有真正的区别

出于某种原因，React 将 的侦听器附加到 DOM 事件。请参阅表单文档中的说明：Component.onChangeelement.oninput

React 文档 - 表单

有更多的人对这种行为感到惊讶。有关更多详细信息，请参阅 React 问题跟踪器上的此问题：

记录 React 的 onChange 与 onInput #3964 的关系

引述关于这个问题的评论：

我不明白为什么 React 选择让 onChange 表现得像 onInput 一样。据我所知，我们没有办法恢复旧的onChange行为。文档声称这是一个“用词不当”，但事实并非如此，当有变化时，它确实会触发，只是直到输入也失去焦点。

对于验证，有时我们不希望显示验证错误，直到它们完成键入。或者，也许我们只是不希望在每次击键时都重新渲染。现在，唯一的方法是使用onBlur，但现在我们还需要检查值是否手动更改。

这没什么大不了的，但在我看来，React 抛弃了一个有用的事件，偏离了标准行为，而当时已经有一个事件可以做到这一点。

我同意100%的评论...但我想现在改变它会带来比它解决的更多的问题，因为已经编写了太多依赖于这种行为的代码。

React 不是官方 Web API 集合的一部分

尽管 React 是建立在 JS 之上的，并且已经看到了巨大的采用率，但作为一项技术，React 的存在是为了在自己的（相当小的）API 下隐藏大量功能。这一点显而易见的领域曾经在事件系统中，在表面下发生了很多事情，实际上与标准的DOM事件系统完全不同。不仅在哪些事件执行什么方面，而且在允许数据在事件处理的哪个阶段持久化方面。您可以在此处阅读更多相关信息：

反应事件系统

没有区别

React 没有默认的 “onChange” 事件的行为。我们在 react 中看到的“onChange”具有默认的“onInput”事件的行为。因此，要回答您的问题，两者在反应方面没有区别。我在GitHub上提出了一个关于同样的问题，这就是他们对此的看法：

我认为在做出这个决定的时候（大约4年前？），onInput在浏览器之间不能一致地工作，并且对于从其他平台访问Web的人来说是令人困惑的，因为他们期望“更改”事件在每次更改时都会触发。在 React 的情况下，这是一个更大的问题，因为如果你不能尽快处理更改，受控输入永远不会更新，导致人们认为 React 已经坏了。因此，该团队在Change上调用了它。

回想起来，在Input上填充并保留其名称而不是更改另一个事件的行为可能是一个更好的主意。但那艘船很久以前就已经航行了。我们可能会在将来重新审视这个决定，但我只是鼓励你把它当作 React DOM 的一个怪癖（你很快就会习惯）。

https://github.com/facebook/react/issues/9567

此外，本文还将提供更多见解。作为默认“onChange”缺失的解决方法，本文建议侦听“onBlur”事件。

https://www.peterbe.com/plog/onchange-in-reactjs