回车键意外提交表单是浏览器默认行为，当表单内仅有一个未禁用的文本输入框时触发；最稳妥解法是改用<div>替代<form>并监听Enter键，或添加隐藏提交按钮占位。
为什么回车键总在意外提交表单
表单里只有一个 <input type="text"> 时，按下回车会直接触发表单提交并刷新页面——这不是 bug，是浏览器的默认行为。哪怕其他字段是 <input type="hidden"> 或被 display: none 隐藏，只要 DOM 中存在且未被 disabled，就可能被忽略，导致“只剩一个可见输入”这个条件成立。
常见错误现象：用户填完搜索框按回车，页面跳转或白屏；多步骤表单中某一步只显示一个输入框，回车后整个流程中断。
- 最稳解法：给表单加
onsubmit="event.preventDefault();"，但别只靠它——语义上你本就不该让这个表单有提交语义 - 更干净的做法：把单输入场景的
<form>换成<div>，用keydown监听Enter，手动触发逻辑 - 如果必须保留
<form>（比如要兼容自动填充或某些框架），至少加一个不可见但可聚焦的冗余输入：<input type="submit" style="position: absolute; left: -9999px;">，它能“占位”，阻止浏览器判定为“单文本输入”
tabindex="-1" 和 tabindex="0" 到底怎么选
tabindex="-1" 是让你的元素能被 JS 主动聚焦（el.focus()），但不会进入 Tab 键自然流；tabindex="0" 才让它真正加入键盘导航顺序，和原生按钮、链接一样被 Tab 键访问到。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 给自定义按钮写
tabindex="1"：它会被排在所有原生可聚焦元素之后，破坏导航直觉，用户 Tab 十几次才轮到你的按钮 - 只加
tabindex="0"却不设role="button"：屏幕阅读器读不出它是按钮，只当普通文字；iOS VoiceOver 下甚至可能跳过 - 对
display: none或visibility: hidden的元素调用.focus()：静默失败，无报错也无效果
实操建议：模态框打开后，立刻 firstFocusableElement.focus()，且该元素必须带 tabindex="0" 或是原生可聚焦标签（如 <button>）。
方向键导航必须监听 keydown 而非 keyup
处理上下左右键时用 keyup，大概率会失效。因为 keyup 触发时，浏览器可能已经执行了默认滚动行为（比如 ArrowDown 让页面下滚），你的焦点移动逻辑被挤到后面，或者被 preventDefault() 拦不住。
正确做法：
- 监听
keydown，并在第一时间调用event.preventDefault() - 优先判断
event.key（如"ArrowDown"），不是event.code（如"ArrowDown"或"Down"，因设备而异） - Home/End 键需单独处理：它们不走方向键逻辑，但用户期望跳到首项/末项，别指望 Tab 循环覆盖
- 避免在
keydown回调里做 DOM 查询（如querySelectorAll），提前缓存好焦点索引或元素列表
软键盘弹出时 input 被遮挡怎么办
移动端最常被忽略的一点：用户点击 <input>，软键盘弹出，但输入框被顶出视口，用户看不到自己在输什么。这不是 CSS 布局问题，而是滚动时机没抓准。
关键动作是监听 focus 事件，然后调用 scrollIntoView({ behavior: 'smooth', block: 'nearest' })。但要注意：
- iOS Safari 对
scrollIntoView的behavior支持不稳定，生产环境建议降级为scrollIntoView(true) - 必须配合
env(safe-area-inset-bottom)做底部留白，否则键盘收起后页面可能残留空白或错位 - 别等
focusin再滚动——有时 focus 事件还没冒泡完，键盘已弹出，滚动失效；改用focus+setTimeout(..., 0)确保在下一个宏任务执行
复杂点在于：如果表单在 modal 或 fixed 容器里，scrollIntoView 可能作用于错误的滚动上下文。这时候得手动计算位置，用 element.getBoundingClientRect() 判断是否在视口内，再决定是否滚动父容器。
