focus()不会自动滚动到可视区域，需手动调用scrollintoview；应按tabindex或语义顺序聚焦首个非法项，跳过disabled/readonly元素；vue中需nexttick后聚焦；移动端safari要求focus必须在用户手势同步链内执行。
focus() 不会自动滚动到可视区域，得手动配合 scrollIntoView
直接调用 element.focus() 只会让元素获得焦点，但若它在视口外（比如长表单底部、折叠面板里、或被 sticky 头部遮挡），用户根本看不到——这反而加重操作负担。必须补上滚动逻辑。
-
element.focus()后立即执行element.scrollIntoView({ behavior: 'smooth', block: 'center' }) - 如果表单有固定头部或侧边栏，加
scrollIntoView({ block: 'nearest', inline: 'nearest' })避免过度滚动 - 部分老浏览器不支持
scrollIntoView的 options 参数，可降级为element.scrollIntoView()（无动画、默认 top 对齐）
校验失败后 focus 第一个非法项，别用 querySelectorAll[0] 硬取
常见错误是遍历所有输入框，收集所有验证失败的元素，再对 Array.from(...)[0] 调用 focus——但 DOM 顺序 ≠ 表单逻辑顺序（比如视觉上从左到右两列布局，DOM 却是上下堆叠）。用户会困惑“为什么光标跳到了奇怪的位置？”
- 按
tabindex顺序查找：用document.querySelectorAll('[tabindex]:not([tabindex="-1"])')+ 过滤非法项，再取第一个 - 更稳妥的是按表单域的
name或语义结构（如fieldset内顺序）维护校验顺序数组，而非依赖 DOM 物理位置 - 若使用 Element Plus 或 Ant Design Vue，它们的
form.validate()回调通常返回错误字段名，可据此反查对应ref元素
disabled 或 readonly 元素不能 focus，得提前跳过
当某个输入框因业务逻辑被设为 disabled 或 readonly，但校验仍把它判为“非法”（比如后端返回必填却禁用了该字段），element.focus() 会静默失败，且不报错——光标卡住，用户以为功能坏了。
- 聚焦前务必检查：
if (!element.disabled && !element.hasAttribute('readonly')) { element.focus(); } - 对
disabled字段，应改用视觉提示（如红边框 + 错误文案），并聚焦其邻近可编辑字段（例如同一组 radio 中下一个input[type="radio"]） - Vue 场景下注意响应式更新时机：
nextTick后再尝试 focus，否则 DOM 可能尚未渲染出目标元素
移动端 Safari 对 autofocus 和 focus 的限制很严格
iOS Safari 默认禁止 JS 主动触发 focus()（尤其页面加载时或异步回调中），除非发生在用户手势事件（如 click、touchend）的同步执行链内。否则 focus 被忽略，且无任何提示。
- 确保校验和 focus 发生在用户点击“提交”按钮的事件处理器内，不要丢进
setTimeout或 API 回调里 - 若需异步校验（如防重复提交、远程校验），先用
button.setAttribute('disabled', '')防止二次点击，校验完成后再同步 focus —— 仍在原事件上下文中 - 实在无法满足同步条件时，退而求其次：用
element.classList.add('invalid-highlight')配合 CSS 动画闪烁，比静默失败更友好
