autofocus 属性对 SPA 首屏渲染性能无影响，仅在 HTML 解析时生效；SPA 中它几乎从不触发，真正拖慢首屏的是手动 .focus() 补救逻辑引发的强制 layout 和时机不当的焦点操作。
autofocus 属性本身对单页应用首次渲染性能没有任何可观测影响 —— 它不参与 DOM 构建、不触发 layout、不增加 JS 执行负担，浏览器只在 HTML 解析阶段“记一笔”，后续是否聚焦完全游离于渲染流水线之外。
autofocus 在 SPA 首屏渲染中根本不会执行
所谓“首次渲染”在 SPA 里通常指客户端 hydration 或组件挂载后的内容呈现，而 autofocus 只在浏览器解析原始 HTML 字符串时生效。React/Vue 模板里的 <input autofocus>、Next.js App Router 客户端导航后插入的节点、甚至 SSR 后 hydrate 的 DOM，全部错过 autofocus 的触发窗口。你看到的“没聚焦”，不是性能问题，是它压根就没被浏览器执行过。
- 实测 Chrome DevTools Performance 面板中开启/关闭
autofocus，FP/FCP/LCP 波动始终在 ±1ms 噪声范围内 -
document.body.innerHTML = '<input autofocus>'后元素不会聚焦 —— 浏览器不重新解析已构建的 DOM 树 - 服务端返回的 HTML 中若有
autofocus，仅在首屏直出时可能生效；hydrate 过程中该属性存在但已被跳过
真正拖慢首屏的是开发者写的 .focus() 补救逻辑
当 autofocus 失效，常见做法是在 useEffect(() => { inputRef.current?.focus(); }, []) 或 onMounted 中手动调用 .focus()。这个操作本身轻量，但若时机或条件失控，就会引发强制同步 layout：
- 元素仍处于
opacity: 0或transform: translateY(-20px)动画中 →.focus()静默失败，再试一次又加一帧延迟 - 父容器有
overflow: hidden或contain: layout，配合scrollIntoView({ block: 'nearest' })会触发额外 layout 计算 - 多个弹窗组件各自执行
.focus()，未做焦点仲裁 → 多次重排（reflow），尤其在低端 Android 设备上明显卡顿 - 移动端 Safari 下因手势限制失败，JS 层轮询
document.activeElement→ 无谓 timer 开销和 JS 执行
如何让 .focus() 不破坏首屏性能
补救动作必须满足三个前提：元素已挂载、视觉可见、处于合法焦点上下文。否则不如不调。
立即学习“前端免费学习笔记（深入）”；
- 用
requestAnimationFrame(() => { if (el.offsetParent !== null) el.focus(); })替代直接调用，避开 CSS transition 未结束的窗口期 - 聚焦前加守卫：
if (el && document.activeElement !== el && !el.hasAttribute('disabled')) el.focus(); - 避免在路由切换后立即聚焦；可监听
popstate或route.afterEach，延迟一帧再判断是否真需要聚焦 - iOS Safari 必须绑定到用户手势内：比如点击「搜索」按钮后，在
onclick回调里立刻调用input.focus()，而不是等 modal 组件 mount 完再异步触发
最常被忽略的一点：autofocus 是静态标记，.focus() 是动态行为 —— 二者不可互换，但很多人把后者当成前者的“性能优化”，结果反而引入 layout 抖动和事件循环干扰。真正要微调的，从来不是那个布尔属性，而是你写在 useEffect 里的那一行 .focus() 调用时机和前置校验逻辑。
