1. https://github.com/facebook/react/blob/master/src/browser/ui/dom/getEventKey.js#L103
2. 这应该已经被Improve normalization of charCode, fix FF not reporting Enter #1956修复了
3. 无法确定大写锁定状态，因此除非有其他提示，否则我相信这绝对是不可避免的浏览器限制。

我不太确定https://github.com/facebook/react/blob/master/src/browser/ui/dom/getEventKey.js#L103 的注解是什么意思，因为它对我来说并不是很清楚。这是否意味着 keyCode 根据键盘布局而变化？
无论如何，如果我们不想在 keydown 和 keyup 中的 key 属性中包含可打印字符，我们应该在所有浏览器中始终这样做，并在适当的时候对事件进行规范化。目前，Firefox 和 Chrome 在这里的行为是不同的。

@Daniel15 keyCode 指的是“虚拟键码”，即键盘上按键的ID。从技术上讲，除非你知道键盘布局，否则它毫无用处。但幸运的是，我们可能遇到的所有键盘都同意(大多数)功能键。没有办法确定键盘布局(包括大写锁定状态等),因此我们实际上无法为可打印按键提供polyfill。
我不同意根据我们目标的浏览器限制 key 支持。对于那些具有原生支持并报告字符值或更完整按键集的浏览器，我们没有从中获得任何好处。然而，当前的原生 key 支持是一个混乱(并且有些损坏)的问题，因此对于损坏的浏览器明确忽略原生 key 有一些道理，但我认为这不是我们真正想要玩的游戏(而且我认为没有需求来证明开发成本是合理的)。

我们通过报告在浏览器中有原生支持且确实报告字符值或更完整一组键的 Unidentified 来获得什么好处。我不同意，我认为我们获得了预期行为的基线以及可以安全依赖的内容。目前，某人可能正在使用 key 作为可打印键，甚至不知道它仅在 Firefox 中有效。
人们使用像 jQuery 和 MooTools 这样的语言库的整个原因是它们平滑了浏览器兼容性问题并提供了良好的基线功能。如果你编写了一些 jQuery 事件处理代码，你基本上可以确定它在跨浏览器中将以相同的方式工作。React 的事件系统应该做同样的事情并提供同等的跨浏览器支持。

如果我们无法做到这一点，至少在帮助中有一个大的警告，解释 key 是不可靠的，除了功能键之外不应该依赖它。

我用 latest 16 release 进行了测试：

• key 对于 Chrome 和 Firefox 中的 keydown/keyup 事件似乎是正确的。
• Chrome 和 Firefox 只为 Enter 键触发 keypress 和 keydown 事件。This W3C keyboard event fixture 表示这两个浏览器确实触发了 keyup 事件。
• 根据 W3C 规范：当 CapsLock 被启用时，Chrome 会触发一个 keydown 事件，当它被禁用时，会触发一个 keyup 事件。Firefox 在这两种情况下都只触发一个 keydown 事件。React 与此一致，只是在 Chrome 中不触发 keyup 事件。