多步骤表单校验需避免原生reportValidity()全局扫描问题，应遍历当前步可见可聚焦字段单独调用el.reportValidity()，动态管理required、disabled及customValidity，并在校验通过后更新currentStep。
多步骤表单的校验不是“每步加个 required 就完事”，核心矛盾在于：浏览器原生校验（checkValidity()、reportValidity()）默认扫全表单，而你只想校验当前可见步骤——不处理好，用户点“下一步”会突然弹出上一步的错误提示，或完全没反馈却卡住不动。
为什么 form.reportValidity() 在多步骤里经常失效
它只对当前可见（offsetParent !== null）且可聚焦的字段触发 UI 提示。被 display: none 或 hidden 的字段，即使 checkValidity() 返回 false，也不会显示气泡错误。更糟的是，如果某字段曾调用过 setCustomValidity('xxx') 但没清空，它的 validity.valid 会一直为 false，导致整个表单校验失败却无提示。
- 别依赖
form.reportValidity()做跨步骤校验；改用遍历form.elements，对每个元素单独调用el.reportValidity() - 每次切换步骤前，手动重置上一步所有字段的自定义状态：
el.setCustomValidity('')+ 清除invalid类 - 隐藏字段若仍保留在 DOM 中（如用
hidden属性），必须参与校验逻辑；若用display: none，得确保 JS 校验函数跳过它们
如何让 required 属性只作用于当前步骤
required 是全局生效的，浏览器不认“当前步”这个概念。直接保留所有步骤的 required，点第一步“下一步”时，第二、三步的必填字段会立刻报错，干扰用户。
- 动态开关
required：切到第n步前，给[data-step="n"] [required]加required属性，同时移除其他步骤中所有required属性 - 或者统一不用
required，改用 JS 手动校验每个步骤的字段是否为空/格式合法——控制力更强，也避免和隐藏逻辑冲突 - 禁用字段（
disabled）不会被提交，也不会参与校验，适合临时屏蔽非当前步控件，但需注意：disabled 字段的值不会进FormData
validateStepX() 函数该怎么写才靠谱
每个步骤的校验函数不能只检查“是否为空”，得覆盖字段存在性、格式、前后一致性（比如两次输入密码）、以及是否被正确启用（disabled 状态）。
立即学习“前端免费学习笔记（深入）”；
- 先过滤掉
disabled或hidden的字段：Array.from(form.elements).filter(el => !el.disabled && el.offsetParent) - 对每个字段调用
el.checkValidity()，而非只看el.value；否则绕过原生约束（如type="email"格式） - 密码二次确认必须在
validateStep2()里显式比对两个input值，不能只靠required - 返回布尔值，且校验失败时同步调用
el.reportValidity()—— 这是唯一能强制触发 UI 提示的方式
currentStep 变量更新前必须完成校验
这是最常被跳过的临界点。用户点“下一步”，JS 如果先执行 currentStep++ 再校验，步骤条就提前高亮，但数据可能根本没过审。视觉欺骗比功能卡住更伤体验。
- 点击事件里第一行就调用对应校验函数，比如
if (!validateStep1()) return - 校验通过后，再更新
currentStep，然后批量更新 UI：progress.value = currentStep、document.querySelector('[data-step="' + currentStep + '"]').removeAttribute('hidden')等 - 后退按钮同理：先更新
currentStep，再手动聚焦当前步第一个有效字段，别等用户自己 Tab
真正难的不是写校验逻辑，而是让每个字段的状态（DOM 存在性、disabled、required、customValidity、焦点、ARIA 属性）全部与 currentStep 同步。漏掉任意一环，屏幕阅读器读错、键盘用户卡住、或用户看到“已完成”却提交失败，都是必然结果。
