tabindex="0" 是让 div、span 等非表单元素支持 Tab 导航的最安全方式，使其按 DOM 顺序加入焦点流；需配合 role 语义、keydown 监听（Enter/Space）及 event.preventDefault() 才能完整支持键盘操作。
能，但前提是正确配置元素可聚焦性、监听事件并管理焦点流——光靠按 Tab 键本身不会“提升”导航，真正起作用的是 tabindex、focus() 和对 keydown 的精准拦截。
怎么让 div、span 这类非表单元素支持键盘 Tab 导航
原生 div 或 span 默认不在 Tab 导航流中，必须显式声明可聚焦能力：
-
tabindex="0"是最安全的选择：元素按 DOM 顺序加入 Tab 流，不打乱逻辑，屏幕阅读器也能识别 - 避免
tabindex="1"或更高正数：它会强行插入焦点顺序，导致键盘用户跳转错乱，尤其在动态渲染内容里极易失效 -
tabindex="-1"只用于 JS 主动聚焦（比如模态框打开后el.focus()），不能靠 Tab 键到达 - 别忘了语义补充：如果这个
div实际是按钮或链接，加role="button"或role="link"，否则屏幕阅读器读不出可操作性
为什么按 Enter/Space 没反应，即使元素已加 tabindex="0"
加了 tabindex="0" 只解决“能被 Tab 到”，不等于“按键有行为”。键盘用户不会点击，他们按 Enter 或 Space 触发动作：
- 必须手动监听
keydown，判断event.key === 'Enter'或event.key === ' '（注意空格是字符串空格，不是'Space'） - 对
Space必须调用event.preventDefault()，否则页面会向下滚动 - 别用已废弃的
keyCode，统一用event.key或event.code - 如果用了
role="button"却没绑keydown，屏幕阅读器会报“该元素不可操作”，但用户实际按了没反馈
监听 document.keydown 做全局快捷键时，怎么避免干扰输入框
全局监听最大的坑，就是用户正在 <input> 里打字，你却把 Ctrl+F 拦下来去开搜索面板——这属于破坏基础交互。
立即学习“前端免费学习笔记（深入）”；
- 先检查
document.activeElement：若tagName是'INPUT'、'TEXTAREA'、'SELECT'，直接 return - 再补一层
!event.target.isContentEditable，覆盖contenteditable="true"的富文本区域 - 优先用
keydown而非keyup：前者响应快，且能及时event.preventDefault()拦截默认行为（比如F5刷新） - 避开
Alt组合键：Windows/Linux 系统级快捷键多用Alt，Mac 用Meta更稳妥；Ctrl在 Windows/Linux、Meta在 Mac 是更安全的通用键位
focus() 调用后，为什么键盘操作还是不生效
element.focus() 只是把焦点设过去，不代表该元素具备完整键盘响应能力：
- 确保元素有
tabindex="0"（或原生可聚焦属性），否则focus()成功但 Tab 键无法继续往下走 - 如果元素是自定义组件（比如封装的下拉菜单），需手动处理
ArrowDown/ArrowUp等导航键，仅靠focus()不会自动激活内部选项 - 移动端软键盘唤起后，部分浏览器会重置焦点或滚动异常，建议在
focus()后加setTimeout(() => el.scrollIntoView({ block: 'nearest' }), 0)补偿 - 不要在
focus()后立刻触发其他 DOM 操作（如隐藏父容器），可能造成焦点丢失且不可恢复
最容易被忽略的是：焦点管理不是一次性的操作，而是一整条链——从元素能否被 Tab 到、是否响应 Enter/Space、到全局快捷键是否放行输入框、再到 focus() 后能否继续导航。任何一个环节断掉，键盘用户就卡住了。
