autofocus在ios safari中完全失效，因苹果底层策略静默拦截非用户手势触发的聚焦；必须在click/touchstart等事件同步回调中立即调用focus()，且确保元素已挂载可见。
autofocus 属性在 iOS Safari 中根本不起作用
直接写 autofocus 在 iOS Safari 和 WKWebView 里是无效的，不是你漏写了属性或 DOM 没加载完，而是苹果从底层就屏蔽了它。浏览器解析 HTML 时确实会识别这个属性，但系统策略直接拦截后续聚焦行为——不报错、不警告、光标不动、键盘不弹。
常见误判场景：
- Vue/React 组件里模板写
<input autofocus>，但渲染后没聚焦 - 页面 onload 后调用
input.focus()，安卓正常，iPhone 静默失败 - 用
setTimeout延迟 0ms 再 focus，依然无效（已脱离用户手势上下文）
必须绑定在用户真实点击事件中同步调用 focus()
iOS 要求 focus() 必须发生在用户触摸/点击触发的**同步执行流**里，且不能跨任务队列。这是唯一稳定生效的路径。
正确做法：
- 按钮点击后立即显示输入框（比如模态框），并在同一函数内调用
inputRef.current.focus()或inputElement.focus() - 确保 input 元素此时已挂载且可见（避开
v-if或display: none状态） - 不要在
Promise.then、$nextTick、useEffect里调用——哪怕只晚一个微任务，也可能失败（尤其 iOS 12–14）
示例（原生 JS）：
document.getElementById('openFormBtn').addEventListener('click', () => {
document.getElementById('myInput').style.display = 'block';
// 紧接着同步聚焦
document.getElementById('myInput').focus();
});
uni-app 或 Vue 项目中怎么安全聚焦
框架接管了 DOM 生命周期，不能依赖 HTML 解析时机。关键不是“什么时候渲染”，而是“什么时候能保证用户刚点完、DOM 已存在、focus 调用在同一个同步栈”。
实操要点：
- 用
ref拿到 input 实例，别用querySelector（可能取不到） - 聚焦逻辑必须放在用户交互事件处理器里，比如
@click="handleOpenAndFocus" - 如果 input 是通过
v-if控制显隐，先设showInput = true，再用this.$nextTick(() => this.$refs.input.focus())——注意：这仅在 iOS 15+ 有一定成功率，旧系统仍建议改用v-show配合同步 focus - SSR 场景下加
if (typeof window !== 'undefined')判断，否则服务端报错
WKWebView 原生侧需配合关闭 keyboardDisplayRequiresUserAction
如果你开发的是混合 App（非纯 H5），仅前端改代码还不够。iOS 12+ 的 WKWebView 默认仍启用 keyboardDisplayRequiresUserAction = true，必须原生层显式关闭。
Swift 示例：
let webView = WKWebView() webView.keyboardDisplayRequiresUserAction = false
注意：
- 该设置必须在创建 WKWebView 实例后、加载网页前执行
- UIWebView 已废弃，
setKeyboardDisplayRequiresUserAction:NO不适用于 WKWebView - 即使原生侧开了开关，前端仍要遵守“用户手势内同步 focus”，否则部分 iOS 版本（如 16.4）仍会拦截
真正卡住的地方往往不是 JS 写错了，而是把“用户刚点下”和“JS 执行 focus”这两件事分开了——哪怕只隔了一个 Promise 微任务，iOS 就当它不是用户干的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
