dialog 中 autofocus 无效，需在 showmodal 后监听 focusin 事件手动 focus，并确保 ios safari 中聚焦操作位于用户手势同步流内，同时补全 aria 属性与焦点陷阱。
dialog 里写 autofocus 基本没用
autofocus 属性只在 HTML 初始解析时生效，而 <dialog></dialog> 元素默认不渲染（display: none），浏览器压根不会处理它内部的 autofocus。哪怕你写了 <dialog><input autofocus></dialog>，只要 dialog 没调用 showModal() 或没加 open 属性，这个 autofocus 就是死代码——不报错，也不聚焦。
更麻烦的是：即使你提前加了 open 属性让它初始可见，autofocus 也只对首个可聚焦元素起作用；如果页面里还有其他带 autofocus 的 input（比如导航栏搜索框），dialog 里的那个大概率被跳过。
- autofocus 不随
showModal()重新触发，dialog 显示后不会“补聚焦” - 多个
<dialog></dialog>同时存在时，只有第一个解析到的autofocus元素可能生效，其余全忽略 -
autofocus不会触发focus事件，没法靠监听做后续逻辑
dialog 显示后手动 focus() 的正确时机
必须等 dialog 真正进入可聚焦状态再调用 .focus()，否则静默失败。常见错误是刚调完 dialog.showModal() 就立刻 input.focus()，但此时元素可能还在 CSS transition 中、父容器 opacity 是 0、或被 inert 锁住。
- 推荐监听
dialog.addEventListener('focusin', handler, { once: true })，等焦点真正进入 dialog 上下文后再聚焦目标 input - 避免用
setTimeout(() => input.focus(), 0)—— DOM 可能还没完成布局，offsetParent === null仍为真 - 用
requestAnimationFrame(() => { if (input.offsetParent !== null) input.focus(); })更稳妥，但不如focusin事件精准 - 务必检查
input.disabled === false且input.tabIndex !== -1，否则.focus()会直接退出
iOS Safari 下 focus() 必须绑定用户手势
在 iOS Safari 中，.focus() 调用若不在用户点击/触摸的同步执行流中，会被浏览器直接拦截——光标不动、键盘不弹，且无任何错误提示。这意味着：
- 不能在路由跳转后、API 响应后、或
useEffect/onMounted里直接调用focus() - 必须把
dialog.showModal()和input.focus()放在同一个 click/touchstart 回调末尾，中间不能穿插异步操作 - 如果弹窗由按钮点击间接触发（比如先发请求，再显示 dialog），需缓存原始事件对象，在响应成功后立即复用
event.target上下文调用focus() - 哪怕用了
requestAnimationFrame或Promise.resolve().then()，只要脱离了原始事件循环，iOS 就拒绝聚焦
别漏掉可访问性配套处理
只让 input 获得焦点远远不够。屏幕阅读器需要知道这是个活跃模态区域，且 Tab 键必须限制在 dialog 内部循环。autofocus 本身不提供这些能力，全靠手动补全：
- dialog 根元素必须有
role="dialog"和aria-modal="true" - 必须设置
aria-labelledby指向一个存在的标题元素（不能是空文本或display: none） - 焦点进入后，要实现 focus trap：监听
keydown捕获 Tab 键，按需将焦点循环到第一个/最后一个可聚焦子元素 - 关闭 dialog 时，必须手动把焦点还给触发它的按钮（
triggerButton.focus()），否则 Tab 键可能跳到不可见区域或背景页面
真正难的不是让光标出现在输入框里，而是让整个焦点流向可控、可预测、不逃逸——这点一上线就容易被无障碍测试卡住，但往往被开发阶段跳过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
