直接给<td>加tabindex="0"会破坏表格语义和导航逻辑，导致焦点按列线性遍历而非按行导航，体验崩坏；正确做法是让<tr>承担焦点容器角色，配合focus-within和方向键事件手动管理单元格内切换。
为什么直接给 <td> 加 tabindex="0" 会失败
因为 <td> 默认不可聚焦，加了 tabindex="0" 确实能进 Tab 流，但浏览器会按 DOM 顺序遍历所有带 tabindex="0" 的 <td> —— 这意味着焦点会从第1行第1列 → 第1行第2列 → … → 第1行最后一列 → 第2行第1列，完全跳过行语义。用户无法“按行导航”，更没法用方向键控制；而且一旦表格列数多，Tab 键要按几十下才能到下一行，体验崩坏。
正确做法：让 <tr> 成为焦点容器，<td> 不参与 Tab 流
把焦点逻辑上收一级，用 <tr> 承担“可聚焦单元”的角色，内部 <td> 仅作内容承载，不设 tabindex（除非是操作按钮等独立控件）：
-
<tr tabindex="0">—— 让整行可被 Tab 键到达，且保持 DOM 顺序自然流转（第1行 → 第2行 → …） - 移除所有
<td>上的tabindex属性，避免污染焦点流 - 若某列含操作按钮（如编辑、删除），该按钮必须是原生可聚焦元素（
<button>或带tabindex="0"的伪控件），且放在该<td>内最末位置，确保 Tab 进入<tr>后，再按一次 Tab 自动落到它上面 - 用
:focus-within控制视觉反馈（比如高亮整行），而非只靠<tr>:focus—— 因为焦点实际在按钮上时，<tr>仍需保持高亮态
如何支持方向键在单元格内切换（非 Tab）
仅靠 Tab 键只能行级跳转，真要实现“上下左右在单元格间移动”，必须拦截 keydown 并手动管理焦点：
- 为每个
<tr>绑定keydown事件，检测event.key是否为"ArrowUp"/"ArrowDown"/"ArrowLeft"/"ArrowRight" - 方向键默认不触发任何行为，需
event.preventDefault() - 根据当前聚焦的
<tr>和光标位置，计算目标<td>或相邻<tr>中对应列的控件（如输入框、按钮），然后调用.focus() - 特别注意边界：到首行再按 ↑、末列再按 → 时，应停止或循环，别让
.focus()失败静默吞掉事件
容易被忽略的兼容性细节
这套方案在 Safari 和旧版 Edge 上容易出问题，不是因为 tabindex 写错，而是底层聚焦机制差异：
立即学习“前端免费学习笔记（深入）”；
- 移动端 Safari 要求元素曾被用户主动触摸过，首次加载后
<tr tabindex="0">可能完全无法被 Tab 到 —— 解决办法是在页面初始化后，对第一行<tr>主动调用.focus({preventScroll: false})（不要传preventScroll: true，Safari 不支持） -
<tr>上设tabindex="0"后，若 CSS 用了display: block或outline: none且没补:focus-visible，键盘用户根本看不到焦点在哪 - 动态渲染的表格（如 React/Vue 渲染），
tabindex必须在 DOM 插入后立即设置，不能依赖初始 HTML；否则 SSR 和客户端 hydration 后焦点流会错乱
