在Safari浏览器（尤其是iOS版）中，给 input 标签加上 autofocus 属性，或者通过 JavaScript 调用 focus() 方法时，你可能会遇到一个让人抓狂的场景：键盘不弹出来，光标也不出现。

代码怎么看都没有问题。但这真的不是你写错了代码，也不是 DOM 还没加载好——而是 Safari 主动拦截了这次聚焦请求，因为它只认“用户亲手点过”的那一刻。

根本原因：Safari 强制执行“用户手势”验证

iOS Safari 和 WKWebView 内核有一个硬性要求：任何触发软键盘的行为——也就是 input 获得焦点——必须发生在 由用户真实触摸或点击事件直接驱动的同步执行上下文 中。

页面加载事件、定时器回调、Vue 的 mounted 钩子、Promise.then，甚至 $nextTick 的微任务，只要脱离了那个“用户刚点下按钮”的原始调用栈，就会被系统静默拒绝。

这可不是一个 Bug，而是苹果 HIG（人机界面指南）明确倡导的设计原则。目的很明确：防止页面在未经允许的情况下突然弹出键盘，遮挡内容、打断用户浏览、引发意外的滚动——说白了，就是要保护用户的交互体验。

哪些操作一定会被忽略？

• 方法一：HTML 原生 autofocus 属性
  在 iOS Safari 中，这个属性完全无效。不管页面结构多简单、input 是不是在首屏、渲染是否已完成，统统不认。
• 方法二：页面加载完成即调用 focus()
  比如 document.addEventListener('DOMContentLoaded', () => { input.focus(); });。这属于典型的“非用户触发”场景，系统直接丢弃调用。控制台不会报错，但键盘就是弹不起来。
• 方法三：异步延迟后聚焦
  哪怕只是 setTimeout(() => input.focus(), 10);——只延迟了 1 毫秒，也已经进入了一个全新的宏任务队列，用户手势的上下文彻底丢失，聚焦必然失败。

为什么 Vue 的 $nextTick 有时能成功？

这其实是一个灰色地带。

第一步：触发时机必须绑定在用户交互事件内

比如在 @click="openModal" 中，先设 showModal = true，再调用 this.$nextTick(() => this.$refs.input.focus())。这个思路是对的。

第二步：理解 $nextTick 的机制

它将回调推入微任务队列。在 Vue 13+ 版本中，Safari 对“紧随用户点击之后的微任务中触发聚焦”容忍度有所提高。但在 iOS 11~12 上，仍然可能失败。需要强调：这只是一个高概率解，不是稳定解。

第三步：避免嵌套异步

不要在 $nextTick 里再套一个 setTimeout，更不要在 API 响应后才去调 $nextTick，否则用户手势链就已经彻底断裂了。

真正可靠的聚焦路径

• 方法1：点击事件处理器内同步聚焦
  确保 DOM 已经存在——比如 input 没有被 v-if 移除——并且 focus() 语句与事件处理函数处于同一个同步执行流中：
  handleClick() { this.showInput = true; // 此时input已挂载 this.$refs.input.focus(); // 同步调用，100%生效 }
  这才是最可靠的做法，没有之一。
• 方法2：为动态插入的 input 绑定 touchstart 监听
  当 input 通过 v-html 或 innerHTML 注入后，立即给它添加一个一次性的 touchstart 监听：
  input.addEventListener('touchstart', function once() { input.focus(); input.removeEventListener('touchstart', once); }, { once: true });
  这相当于把“用户将要点这里”的意图，提前预埋到了元素身上。
• 方法3：原生 click() 模拟（仅限可交互元素）
  如果 input 本身因为 disabled 或 CSS 禁用而无法点击，可以改聚焦它的父容器中的 button 或 label，并设置 for 属性关联 input。利用 label 点击自动聚焦的原生行为，也能达到同样效果。

《夸克》非常好用的免费AI浏览器

下载APP查看