动态增删表格行时，焦点必须精准控制：新增行后立即聚焦首个可操作项，删除行前记录相邻行或触发按钮并聚焦；每行设tabindex="0"和role="row"，配合aria-live播报变更。
动态增删表格行时，焦点不能“消失”或“乱跳”，否则键盘和屏幕阅读器用户会彻底失去上下文。必须在新增行后立即将焦点落到新行第一个可操作项（如输入框），删除行后则需确保焦点回到合理位置（比如上一行、下一行，或触发删除的按钮）。
新增行后焦点必须落到第一个输入框
很多人以为 cloneNode 后 DOM 渲染完就自动可聚焦了，其实不然：新行插入后若不主动 focus()，焦点仍停在原处，用户得按多次 Tab 才能抵达新内容，体验断裂。
- 新增行完成（
table.tBodies[0].appendChild(newRow)）后，立即执行newRow.querySelector('input, select, textarea')并调用.focus() - 目标元素必须有
tabindex="-1"或是原生可聚焦元素（如<input>），否则.focus()静默失败 - 避免用
setTimeout延迟聚焦——它不可靠；推荐用requestAnimationFrame或queueMicrotask确保 DOM 已 commit - iOS Safari 对
.focus()极其敏感：若新行被overflow: hidden的父容器裁剪，或处于display: none状态，聚焦会失败
删除行时焦点不能丢失或跳到页面顶部
直接 row.remove() 后焦点常落到 document.body，导致键盘用户按 Tab 一下就跳到地址栏，完全脱离表单上下文。
- 删除前，先记录当前行的上一行（
row.previousElementSibling）或下一行（row.nextElementSibling），优先聚焦前者；若都不存在，则聚焦触发删除的按钮（需提前保存引用，如button.dataset.deleteTarget = 'edCol3'） - 不要依赖
document.activeElement判断“谁该接收焦点”——它可能已是其他组件（如搜索框）的焦点，不可信 - 若删除的是最后一行且无上/下文，应聚焦表格标题（
<caption>）或表头（<th>），并确保其带tabindex="-1"，否则无法聚焦 - 别用
focus({preventScroll: true})—— Safari 不支持该选项，需降级为普通.focus()并手动scrollIntoView({block: 'nearest'})
每行 <tr> 必须可聚焦且语义清晰
仅靠 CSS :focus 或 JS 模拟高亮，无法让 <tr> 进入 Tab 流。键盘用户 Tab 到这行时，焦点实际落在空白处，操作菜单按钮无法触发。
立即学习“前端免费学习笔记（深入）”；
- 给每行设
tabindex="0"，使其成为合法 Tab 目标；不要用正数（如tabindex="1"），它破坏自然顺序 -
<tr>本身不具语义，需配合role="row"，其子<td>加role="gridcell"，整个<table>加role="grid"，才能被屏幕阅读器识别为数据表格 - 操作按钮（如省略号
<button>）应在行获得焦点后才显示，且必须设tabindex="0"或为原生<button>，否则 Tab 会直接跳过它 - 避免在
<tr>上监听keydown处理方向键——它不是标准交互控件；应把导航逻辑下沉到具体可操作单元（如编辑按钮、状态开关）
动态内容更新时必须通知辅助技术
新增/删除行后，屏幕阅读器不会自动播报“已添加一行”或“第3行已删除”，除非你显式告诉它。
- 在表格外维护一个隐藏的实时播报区：
<div aria-live="polite" aria-atomic="true" class="sr-only"></div>，每次操作后更新其textContent - 新增行后写入 “已添加一行，姓名字段已聚焦”；删除后写入 “第2行已删除，焦点回到第1行” —— 内容要具体，不能只说“已更改”
- 不要用
aria-live="assertive"：它会中断当前朗读，仅适合错误提示等强中断场景 - 该播报区必须静态存在（不随表格重渲染），否则某些屏幕阅读器（如 NVDA）会丢掉通知
最易被忽略的一点是：所有焦点操作都必须与 DOM 生命周期严格对齐。React 中用 useLayoutEffect，Vue 中用 nextTick，原生 JS 中用 requestAnimationFrame —— 任何“稍后聚焦”的模糊表述，都会在 iOS Safari 或低配安卓机上变成静默失败。
