autofocus对<button>支持极差，仅静态页面顶部可见按钮可能生效；动态场景必须用.focus()并校验元素状态、可见性及用户手势时机。
autofocus对
HTML规范允许autofocus用在<button>上，但实际支持度远不如<input type="text">或<textarea>。Chrome和Firefox基本能触发聚焦，Safari（尤其是iOS）经常静默忽略——它不报错，也不抛异常，只是当没这回事。
更关键的是：autofocus只影响焦点位置，不触发点击、不激活按钮行为、也不保证键盘可操作（比如屏幕阅读器可能跳过）。如果你指望用户按回车直接提交，仅靠autofocus远远不够。
- 必须确保按钮未被
disabled，且父容器不能是display: none或visibility: hidden -
tabindex="-1"会彻底禁用自动聚焦，哪怕写了autofocus - 多个
autofocus元素存在时，<button>哪怕排第一，也可能被前面的<input>抢走焦点
什么时候真该用autofocus而不是.focus()？
几乎没有。对<button>来说，autofocus唯一“可行”的场景，是纯静态HTML页面、无JS干预、且按钮就在文档顶部、无任何CSS隐藏——这种场景现在几乎不存在。
现实项目中，按钮往往出现在模态框、条件渲染区块、路由切换后的新视图里。这些全是动态挂载，autofocus压根不会被浏览器解析到。你看到的“没反应”，不是写错了，是它根本没机会运行。
立即学习“前端免费学习笔记（深入）”；
- React/Vue组件里写
<button autofocus>→ hydration后DOM已存在，错过解析时机 - 用
el.innerHTML = '<button autofocus>OK</button>'插入 → 新增节点不触发重新解析 - 模态框初始
display: none，JS切为block后再显示 → 解析时不可见，autofocus被跳过
替代方案：用.focus()手动控制，但得加判断
对<button>调用.focus()比依赖autofocus可靠得多，但仍有坑：如果按钮还没渲染完成、被CSS隐藏、或当前焦点已被用户主动移到别处，.focus()会静默失败。
安全做法是先检查元素状态，再聚焦：
const btn = document.querySelector('#submit-btn');
if (btn &&
btn.offsetParent !== null &&
!btn.hasAttribute('disabled') &&
document.activeElement !== btn) {
btn.focus();
}
-
offsetParent !== null比getComputedStyle(btn).display !== 'none'更准，能识别display: none和visibility: hidden两种隐藏 - 移动端iOS Safari要求聚焦必须发生在用户手势（如
click、touchstart）回调内，否则软键盘不弹出；所以模态框的“打开按钮”点下后，立刻btn.focus()才有效 - 避免在
blur事件里立即focus()，可能被浏览器拦截或引发循环
真正要注意的不是“怎么聚焦”，而是“为什么聚焦”
给按钮加自动聚焦，通常是为了缩短操作路径，比如表单提交后让“确认”按钮获得焦点，方便用户按回车继续。但若按钮不在可视区域、或焦点覆盖了用户正在操作的输入框，体验反而变差。
更隐蔽的问题是可访问性：autofocus会绕过屏幕阅读器的默认阅读顺序，而.focus()配合aria-describedby或aria-live能更好传达上下文。别只盯着能不能聚焦，得想清楚聚焦之后，用户接下来要做什么。
