iOS Safari 中 autofocus 属性和 focus() 方法均受限：autofocus 被主动忽略以防软键盘意外弹出；focus() 必须在用户手势同步上下文中调用，且元素需已渲染、可聚焦、无 iframe 限制。
autofocus 属性在 iOS Safari 中基本不生效
它会被 Safari 主动忽略，无论是否写在 <input>、<textarea> 或 <button> 上。这不是 bug，而是苹果的明确设计策略：防止页面加载时意外弹出软键盘、打断浏览流或引发滚动错位。
为什么 document.getElementById('x').focus() 也常失败
单纯调用 focus() 方法在 iOS Safari 中同样受限——必须发生在用户手势（如 click、touchend）触发的同步执行上下文中，且不能延迟到 setTimeout、Promise.then 或 requestAnimationFrame 里。
- ✅ 正确：在按钮
click回调中立刻调用input.focus() - ❌ 错误：页面
load后直接调用；或在setTimeout(() => input.focus(), 0)中调用 - ⚠️ 注意：
input.select()可以提升兼容性，但前提是focus()已成功执行
SPA 页面中 autofocus 失效的根源
autofocus 是 HTML 解析阶段的行为，只对初始 DOM 中存在的元素起作用。React/Vue 等框架动态渲染的 <input autofocus>，Safari 根本不会识别这个属性——它早已过了解析时机。
- 动态插入的输入框，必须手动调用
focus()，且需绑定到用户交互事件上 - 若组件挂载后立即
useEffect(() => { inputRef.current?.focus(); }, [])，在 iOS 上大概率静默失败 - 推荐做法：提供一个“开始输入”按钮，点击后显式聚焦并展开表单区域
容易被忽略的边界条件
即使满足了用户手势 + 同步调用，以下情况仍会导致 focus() 失效：
- 目标
<input>尚未渲染完成（如还在display: none或visibility: hidden容器中） - 元素被
tabindex="-1"显式禁用聚焦能力 - 页面处于 iframe 内，且父页面未授予
allow="clipboard-read; clipboard-write; focus;" - 用户刚手动点过其他可聚焦元素，iOS 会优先尊重该次交互意图
真正可靠的聚焦，永远建立在“用户明确想输入”这个前提之上，而不是试图绕过它的规则。
