使用JavaScript已废弃特性（如keypress事件）会产生什么后果？

必要性完全取决于你的项目使用场景，没有绝对的“必须全项目零废弃API”的死规矩，但边界非常清晰：

• 如果是写本地跑的临时脚本、个人自用的小工具，生命周期短、用户只有你自己，完全可以怎么顺手怎么写，用废弃API不会有任何问题
• 如果是面向公网用户上线的正式项目、需要长期维护、要求兼容多终端/多浏览器版本，必须主动规避废弃特性，这不是代码洁癖或者规范教条，是最基本的线上稳定性要求。

别信“现在浏览器还支持就可以用”的说法，踩坑都是实打实的：

• 兼容性随时可能断裂：废弃API的本质是已经从Web标准里移除的特性，当前浏览器保留支持只是为了暂时兼容老网站，没有任何长期支持的承诺。比如现在高版本Chrome已经在部分第三方输入法场景下不触发keypress，iOS Safari 15.4之后对软键盘输入的keypress触发逻辑做了裁剪，你现在本地测试全正常，可能下次用户浏览器自动更个新版本，输入拦截功能直接失效，连提前预警都没有。
• 出问题没有任何修复渠道：如果废弃API在某个场景下行为不符合预期——比如大写锁定时返回值错误、死键输入不触发、触控键盘输入漏触发——哪怕给浏览器团队提bug，也不会被受理，官方已经明确不再维护这类特性，所有问题都要自己兜着。
• 逻辑天生存在缺陷：你觉得keypress刚好只响应可打印字符、适配你校验字母数字的需求，实际上它的设计从一开始就有问题：遇到系统快捷键、组合粘贴、输入法联想输入、盲文输入等场景时，它的触发逻辑完全没有统一标准，很容易出现要么误拦截用户正常操作，要么漏过需要校验的输入，这些边缘场景本地测试很难覆盖全，上线就容易出客诉。
• 新环境直接不支持：现在很多非标准浏览器环境，比如小程序内嵌WebView、高版本Electron应用、部分桌面客户端的内嵌网页容器，会直接裁剪掉废弃API的支持，你在普通Chrome上调得再顺，放到这些环境里直接报错，连兼容兜底的机会都没有。

根本不用硬守着keypress，用标准的keydown事件实现你要的逻辑更简单，边缘场景覆盖还更全：

核心思路是在keydown阶段通过event.key判断输入内容，只对单字符的字母、数字做校验，其余功能键、组合键、输入法组合输入的场景直接放行，配合isComposing属性可以完美避开中文输入法的误判。

最小实现代码：

const inputElement = document.querySelector('#your-input')
inputElement.addEventListener('keydown', (e) => {
  // 输入法正在组字时直接放行，不做拦截
  if (e.isComposing) return
  // 判断当前输入是否为单个字母/数字
  const needValidate = /^[a-zA-Z0-9]$/.test(e.key)
  if (!needValidate) return

  // 这里写你原有的校验逻辑，判断该字符是展示还是拦截
  // 需要拦截时调用 e.preventDefault() 即可
})

这个实现所有现代浏览器全支持，移动端、跨端Webview的兼容性拉满，也不用记混乱的keyCode映射表，比用keypress靠谱得多。

内容的提问来源于stack exchange，提问作者Victor