tabindex="0"使元素进入标准tab顺序，tabindex="-1"仅支持js聚焦，禁用正数；需配合role和aria-*提供语义；按钮类交互优先用click事件；动态内容须主动管理焦点。
tabindex 属性怎么设才让键盘导航真正可用
不是所有元素默认支持 Tab 键聚焦，只有原生可交互元素（如 <a></a>、<button></button>、<input>）才有内置键盘导航能力。想让 <div> 或 <code><span></span> 参与导航，必须显式设置 tabindex，但值的选择直接影响行为：
-
tabindex="0"：元素进入标准 Tab 顺序，能用Tab进入，也能用.focus()编程聚焦 -
tabindex="-1"：不能通过Tab到达，但可通过 JS 聚焦（适合模态框首次打开时手动聚焦主内容区） -
tabindex="1"及正数：强制插入 Tab 顺序，极易打乱逻辑流，**强烈不建议**
常见错误是给非交互容器加 tabindex="1"，结果整个页面焦点跳转错乱，用户找不到“下一个该按哪”。
role 和 aria-* 怎么配合 tabindex 构建语义化导航
光有 tabindex 不够。屏幕阅读器需要知道这个可聚焦元素“是什么、能干什么”。比如一个模拟下拉按钮的 <div>，只加 <code>tabindex="0"，读屏软件只会念“空白”，不会提示“下拉菜单，按空格展开”。
必须同步补全 ARIA 语义：
立即学习“前端免费学习笔记（深入）”；
<div tabindex="0" role="button" aria-expanded="false" aria-haspopup="listbox"> 选择城市 </div>
-
role="button"告诉辅助技术这是个按钮 -
aria-expanded动态反映展开状态（JS 中需同步更新） -
aria-haspopup暗示有子菜单，触发后应把焦点移入列表
漏掉任一属性，键盘用户可能无法理解操作意图，或操作后焦点丢失。
键盘事件监听为什么不能只绑 keydown
很多开发者监听 keydown 处理回车/空格触发点击，但忽略了一个关键问题：某些键盘组合（如 Shift+Tab、Ctrl+Tab）会绕过你的监听，直接由浏览器接管。更严重的是，keydown 会捕获所有按键，包括输入法上屏前的拼音键——导致中文输入被意外中断。
正确做法是：
- 对按钮类交互，优先用
click事件（它天然兼容空格/回车触发） - 若必须监听键盘，用
keypress或keyup，并检查event.key是否为"Enter"或" "（空格） - 务必加
if (event.isComposing) return阻止输入法干扰
焦点管理在动态内容中容易被忽略的点
单页应用里，路由切换、弹窗打开、列表筛选后，焦点常常“消失”——用户按 Tab 从上一页残留位置继续走，而不是落到新内容起点。这不是 bug，是没做主动焦点管理。
典型场景和对策：
- 模态框打开：用
element.focus()聚焦第一个可交互项，同时用inert或aria-hidden="true"隐藏背景区域（防止焦点逃逸） - 列表刷新后：如果用户之前聚焦在第 3 条，刷新后第 3 条已不存在，焦点不应卡死，而应回退到列表容器并设
tabindex="-1"，再.focus() - SPA 路由跳转：监听
popstate后，聚焦到main区域或h1，别让用户从顶部重新 tab 十几次
焦点不可见、不可预测，是键盘导航最隐蔽的失败点——它不报错，但会让真实用户彻底卡住。
