异步加载后 focus() 失败主因是dom已插入但渲染未完成或元素被css隐藏；应使用 requestanimationframe 延迟聚焦，并确保元素可聚焦、未禁用、不在 shadow dom 未挂载区域。
异步加载后调用 focus() 失败的常见原因
DOM 插入完成但浏览器尚未完成渲染，或元素被 CSS 隐藏（display: none 或 visibility: hidden），都会导致 element.focus() 静默失败。这不是 JS 错误，而是浏览器拒绝聚焦不可见/未挂载元素。
实操建议：
- 用
requestAnimationFrame()延迟一次绘制周期再聚焦，比setTimeout(..., 0)更可靠 - 检查目标元素是否满足可聚焦前提：是原生可聚焦标签（
input、button等），或已设tabindex="0"，且未被disabled或tabindex="-1"阻断 - 若元素在 Shadow DOM 内，需先确认
shadowRoot已挂载，再查子节点并聚焦
动态表单中如何重新计算焦点陷阱范围
模态框或表单内容通过 AJAX、fetch 或框架指令（如 Vue 的 v-if）动态插入后，原先收集的可聚焦元素列表会过期。继续用旧数组判断首尾元素，会导致 Tab 循环跳空、焦点逃逸。
实操建议：
- 每次内容更新后，必须重新执行
container.querySelectorAll('button, input, select, textarea, [tabindex]:not([tabindex="-1"])') - 不要依赖缓存的
first/last变量；应在keydown回调内实时获取当前可聚焦元素集合，或封装为updateFocusables()方法显式调用 - 使用
tabbable库时，调用trap.update()是必需步骤，否则新增的input不参与循环
为什么不能只监听 keydown 判断 Tab？
仅靠 keydown + event.key === 'Tab' 无法覆盖所有焦点移出场景。用户可能用鼠标点击背景、用屏幕阅读器快捷键跳转、或触发 focusin 事件直接落到外部元素——这些行为都不会触发 keydown，却已破坏焦点陷阱。
实操建议：
- 必须监听容器的
focusin事件（它冒泡，且能捕获任何方式进入的焦点） - 在回调中检查
event.target是否仍在容器内：!container.contains(event.target) - 若不在，立即
first.focus()并event.preventDefault()（注意：此处 preventDefault 对 focusin 无效，聚焦动作本身即为纠正） - 搭配
keydown处理 Tab 方向循环，二者缺一不可
autofocus 在异步表单里是个陷阱
autofocus 属性在 HTML 解析阶段生效，对异步插入的元素完全无效。更危险的是：若你在 JS 中手动给动态插入的 input 加 autofocus 属性再插入，浏览器不会响应——它只认初始 HTML 流中的声明。
实操建议：
- 彻底弃用
autofocus，改用 JS 显式聚焦，且必须配合requestAnimationFrame - 模态框打开后，焦点必须落在第一个可聚焦元素上；这一步漏掉，整个焦点陷阱逻辑就失效
- 关闭模态框时，别忘了把焦点还给触发按钮（保存其引用，比如
triggerBtn），否则键盘用户会迷失在页面顶部
focus() 就会静默失败，且无报错。调试时优先检查这些前置状态，而不是反复重写 keydown 分支。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
