用keydown实现表格Arrow键导航需：给table设tabindex="0"并监听其keydown事件；用event.target.closest('td,th')定位当前单元格；根据方向键计算目标行列索引并越界检查；配合role="grid"等ARIA属性确保可访问性；预先构建cellMap提升大型表格性能。
如何用 keydown 事件实现表格单元格的 Arrow 键导航
原生 HTML 表格不支持方向键跳转单元格，必须手动监听 keydown 并计算焦点位置。关键不是“加事件”，而是正确识别当前聚焦的 <td> 或 <code><th>，再根据按键算出目标单元格索引。<p>常见错误是直接对 <code>document 监听，却没限制作用域——导致在输入框里按方向键也触发跳转。应只在表格获得焦点（或其子元素聚焦）时启用导航逻辑。
- 给
<table> 加 <code>tabindex="0"，使其可聚焦；否则无法捕获键盘事件 - 用
event.target.closest('td, th')安全获取当前单元格，避免event.target是内部按钮/输入框时出错 - ArrowUp/Down 按行索引 ±1，ArrowLeft/Right 按列索引 ±1；需检查目标位置是否越界（
rows[i].cells[j]存在才赋 focus） - 首次聚焦时建议自动聚焦第一个可 tab 的单元格（如
table.querySelector('td, th')），否则用户按方向键无响应 - 用
event.preventDefault()阻止浏览器默认行为，但不要滥用——仅在你确实处理了该快捷键时调用 - 记录当前单元格的
rowIndex和cellIndex，Ctrl+J 即rowIndex + 1，Ctrl+K 即rowIndex - 1 - 若目标行超出范围，可循环跳转（最后一行按 Ctrl+J 跳回第一行），也可静默失败——取决于业务需求
- 避免绑定全局快捷键；应在表格
focusin时添加监听，focusout时移除 <table> 应设 <code>role="grid"，每个<tr> 设 <code>role="row"，每个<td>/<code><th> 设 <code>role="gridcell"或role="columnheader"- 每次焦点切换后，需更新当前单元格的
aria-selected="true"，并清除上一个的该属性 - 禁用
tabindex="-1"给非首行首列单元格——它们必须能被键盘顺序访问（tabindex="0"或默认可 tab） - 若单元格含可交互元素（如
<input>），需用roving tabindex模式：仅当前激活单元格为tabindex="0"，其余为tabindex="-1" - 初始化时遍历一次
table.rows，构建二维数组cellMap[i][j] = cellElement，或扁平对象{'2-5': cell} - 监听
focusin获取当前单元格后，直接从 map 中取cellMap[currentRow][currentCol + 1]，无需 DOM 查找 - 表格动态增删行时，必须同步更新 map——否则索引错乱；静态表格可只初始化一次
- 慎用
querySelectorAll('td, th')获取全部单元格：它返回的是静态 NodeList，后续 DOM 变更不会反映其中
自定义快捷键（如 Ctrl+J / Ctrl+K）跳转到指定行列
Ctrl+J/K 类似 Vim 导航，本质是组合键 + 坐标偏移。不能只靠 event.key === 'j'，必须同时检测 event.ctrlKey，且需阻止默认行为（否则浏览器可能执行“查找”或“打开新窗口”）。
这类快捷键容易和浏览器/编辑器快捷键冲突（例如 Ctrl+K 在 Chrome 是地址栏聚焦），所以建议加前缀或限定激活条件：比如仅当表格有 data-nav-mode="active" 属性时才生效。
立即学习“前端免费学习笔记（深入）”；
保持可访问性：键盘导航必须兼容屏幕阅读器
单纯让 <td> 获得 focus 并不等于可访问。屏幕阅读器依赖语义和 ARIA 属性，而非视觉焦点。<p>最常被忽略的是：未设置 <code>role="grid" 的表格，屏幕阅读器会读作普通布局表格，方向键导航无效；而设置了 role="grid" 后，又必须手动维护 aria-selected 和焦点同步。
性能陷阱：大型表格（>1000 单元格）的焦点计算开销
每次按键都遍历所有 rows 和 cells 查坐标，100 行 × 50 列的表格就要做 5000 次 DOM 查询，卡顿明显。
解决方案不是“优化查询”，而是提前建立索引映射：用 JavaScript 对象缓存每个单元格的坐标，按键时 O(1) 查找目标。
真正麻烦的不是写导航逻辑，而是让键盘焦点、ARIA 状态、DOM 索引三者始终一致。少一步同步，就会出现“焦点在第3行，但 aria-selected 还在第1行”这类隐蔽问题。
