focus()调用失败主因是时机不当或元素状态不符；需在DOMContentLoaded后检查isConnected、offsetParent及disabled等状态，并在iOS Safari中绑定用户手势触发。
focus() 方法在页面加载后调用失败的常见原因
直接写 document.getElementById('search').focus() 却没反应，大概率不是代码写错了，而是时机不对。DOM 还没解析完、元素还没挂载、或者被 CSS 隐藏了，focus() 就会静默失败（不报错，但无效果）。
- 脚本放在
<head>里且没加事件监听 → 此时document.body还不存在，querySelector返回null - 元素在
v-if/*ngIf/{show && <input>}中 → 渲染前 DOM 里根本没这个节点 - 父容器是
display: none或visibility: hidden→ 元素不可见，.focus()被浏览器拒绝 - 元素带
disabled或readonly→ 不可聚焦，调用无效
DOMContentLoaded 和 window.onload 的选择差异
DOMContentLoaded 是更优起点，它等的是 HTML 解析完成、DOM 树构建完毕，不等 CSS/JS/图片加载；而 window.onload 要等全部资源加载完，延迟明显更高，尤其在弱网或大图场景下容易错过用户操作窗口。
- ✅ 推荐：
document.addEventListener('DOMContentLoaded', () => { ... })—— 够快，也够稳 - ⚠️ 注意：
DOMContentLoaded不保证元素已“可见”或“可交互”，仍需校验offsetParent !== null或getComputedStyle(el).display !== 'none' - ❌ 不要用
setTimeout(() => ..., 0)替代事件监听 —— 它不能解决渲染未就绪问题，只是把失败时间点往后挪，反而增加不确定性
聚焦前必须检查的三个状态
哪怕 DOM 已就绪，.focus() 也可能被浏览器跳过。必须显式确认目标元素当前是否满足聚焦前提：
-
是否已挂载：用
el.isConnected判断是否在文档中（比querySelector返回非null更可靠） -
是否可见：用
el.offsetParent !== null（比getComputedStyle轻量，且能覆盖visibility: hidden和display: none） -
是否可聚焦：检查
!el.disabled && !el.readOnly && el.tabIndex !== -1，避免对禁用控件白忙一场
示例片段：
立即学习“前端免费学习笔记（深入）”；
document.addEventListener('DOMContentLoaded', () => {
const input = document.querySelector('#search-input');
if (input && input.isConnected && input.offsetParent !== null && !input.disabled) {
input.focus({ preventScroll: true });
}
});
iOS Safari 下 focus() 必须绑定用户手势
iOS Safari 对非用户触发的聚焦有硬性拦截：页面加载、DOMContentLoaded、定时器、AJAX 回调里的 .focus() 基本都无效，键盘不会弹出，焦点可能设了但不可见。
- ✅ 可靠做法：把
.focus()放在一次真实的用户交互回调里，比如click、touchstart或keydown（仅限首次） - ✅ 示例：
document.body.addEventListener('click', () => { input.focus(); }, { once: true });—— 点一下页面任意处就触发，不干扰 UX - ⚠️ 注意：
preventScroll: true在 iOS 上支持良好，务必加上，否则聚焦可能引发意外滚动遮挡输入框
真正复杂的地方不在怎么写 .focus()，而在判断“现在能不能调”——它依赖 DOM 状态、CSS 可见性、浏览器策略、甚至用户是否刚点过屏幕。autofocus 是个幻觉，.focus() 才是可控的起点，但每一步都得亲手验证。
