onkeydown是在用户按下任意物理按键的瞬间触发的事件，此时input.value尚未更新，也不等输入法上屏，因此不适合做内容校验或字数统计，而适合拦截功能键。
onkeydown 是什么，它到底在哪个时刻触发
onkeydown 在用户手指刚按下任意物理按键的瞬间就触发，不管这个键是否产生字符、是否处于中文输入法中、甚至是否被系统识别为有效输入。它不等 input.value 更新，也不等输入法上屏——此时读取值仍是旧的。
常见错误现象：在 onkeydown 里做实时字数统计、校验长度、过滤非法字符（比如只允许数字），结果发现删掉一个字后计数没变，或者输入字母时校验仍通过。
- 适合拦截功能键：
Enter提交、Tab切换、F5刷新、Escape取消 - 必须配合
event.preventDefault()才能阻止默认行为（例如回车提交表单） - 按住不放会连续触发，中文输入法下拼音每敲一个字母也常触发（
keyCode === 229）
为什么不能用 onkeydown 做输入内容校验
因为校验依赖的是“用户最终输入了什么”，而 onkeydown 触发时，DOM 还没同步新内容。比如在 <input type="text"> 中输入 “a”，按下 a 键那一刻，event.target.value 仍是空字符串。
更麻烦的是中文输入法场景：敲 “nihao” 拼音过程中，onkeydown 会触发多次，但 value 始终不变；直到按空格或回车确认上屏，才真正更新——而这一步是 onkeyup 或 input 事件才捕获到的。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 想限制只能输数字？别在
onkeydown里判断event.key，它对 Backspace、Delete、方向键返回空或不可靠值 - 想实时搜索？用
onkeyup或直接监听input事件，否则用户打完字才开始请求 - 想过滤粘贴内容？
onkeydown根本收不到粘贴事件，得靠onpaste+input
onkeydown 内联写法的坑和替代方案
直接在 HTML 标签里写 onkeydown="handleKey(event)" 看似简单，但很快会失控：逻辑散落在模板里、无法复用、调试困难、破坏语义结构。
更严重的是，内联方式无法访问闭包变量或 React/Vue 组件状态，现代框架里基本弃用。
- 不要这样写：
<input onkeydown="if(event.key==='Enter') submit()"> - 推荐用
addEventListener('keydown', handler)，便于移除、条件绑定、统一管理 - 如果必须用内联（如 CMS 输出的静态页），至少把逻辑抽成独立函数，避免大段脚本塞进属性值
- 注意：某些元素不支持
onkeydown，比如<div>默认不可聚焦，需加tabindex="0"才能响应
比 onkeydown 更靠谱的现代选择：input 事件
如果你真正关心的是“输入框的值变了”，而不是“哪个键被按下了”，那 input 事件才是事实标准。它覆盖所有变更来源：键盘、粘贴、拖放、语音输入、IME 上屏、甚至 JS 脚本赋值（el.value = 'xxx'）。
onkeydown 是低层信号，input 是高层反馈——就像听发动机声 vs 看仪表盘转速。
- 兼容性：Chrome 58+、Firefox 46+、Safari 10.1+、Edge 16+，已足够覆盖当前主流环境
- 中文输入法下表现稳定：只在确认上屏后触发，避开拼音过程干扰
- 无需手动判断
event.key或event.code，直接读event.target.value即可 - 注意：它不会告诉你用户按了什么键，所以快捷键组合（Ctrl+S）还得靠
keydown
最易被忽略的一点：很多开发者以为“监听了 keydown 就等于监听了输入”，其实只是监听了按键动作。真实业务中，绝大多数需求要的不是“按了什么键”，而是“现在框里有什么”——这个分界点，决定了该用哪个事件。
