fieldset核心作用是启用浏览器原生分组能力，包括局部验证、整组禁用、键盘导航边界和屏幕阅读器语义播报；必须配legend为首个子元素，否则语义失效，仅剩空壳。
多步骤表单里用 fieldset 不是为了加边框，而是为了启用浏览器原生的分组控制能力——包括局部验证、整组禁用、键盘导航边界和屏幕阅读器语义播报。不按规范用，fieldset 就只剩个空壳。
为什么“下一步”按钮总触发全局验证？
根本原因是没给非提交按钮设 type="button"。HTML 中未声明 type 的 <button> 默认是 type="submit"，点击即触发表单级验证，哪怕目标 fieldset 还没显示。
- 所有“下一步”“上一步”按钮必须显式写
type="button"，哪怕它们在form内部 -
form.checkValidity()或input.checkValidity()不会阻止默认提交行为，只有event.preventDefault()或正确设置按钮类型才能拦住 - 若仍想保留原生
required提示气泡，只对当前fieldset.active input调用checkValidity()，但绝不依赖按钮默认行为
如何让每步 fieldset 独立验证且不互相干扰？
靠 CSS 类控制可见性 + JS 限定验证范围，而不是靠 display: none 或 hidden 属性隐藏字段——后者会让 checkValidity() 返回 true（因为不可见控件不参与验证），但用户看不到错误提示。
- 用
fieldset.active+fieldset:not(.active)控制显隐，确保非活跃字段仍在 DOM 中、可被querySelectorAll捕获 - 验证逻辑只查
document.querySelectorAll('fieldset.active input')，跳过disabled或readonly字段（它们不影响checkValidity()结果） - 不要给非当前步的
fieldset加disabled——它会彻底禁用内部控件，导致用户无法聚焦或输入，即使你后续再移除disabled，焦点状态也可能丢失
fieldset.disabled 在多步骤中容易踩哪些坑？
它确实能一键锁死整组字段，但副作用太强：不仅禁用交互，还让字段值从 FormData 和 form.elements 中消失，且 Safari 对嵌套 fieldset 的禁用传递不稳定。
立即学习“前端免费学习笔记（深入）”；
- 需要“视觉禁用但保留可编辑权”时，改用
fieldset[aria-disabled="true"]+ CSS 灰阶样式，再用 JS 手动拦截输入事件 - 若某步需根据条件启用/禁用字段（如“是否邮寄发票”勾选后才激活地址栏），把
disabled加在具体input上，而非整个fieldset - 测试时务必用真实设备验证 iOS Safari —— 它对
fieldset[disabled]下label的点击穿透支持不一致，有时点 label 无法聚焦对应 input
legend 标签写错位置会导致什么后果？
legend 必须是 fieldset 的**第一个子元素**，否则屏幕阅读器无法将其识别为该组的可访问名称，键盘 Tab 导航也会跳过整组。
- 错误：
<fieldset><div class="header"><h3>收货信息</h3></div><input name="addr"></fieldset>→ 读屏软件完全忽略分组意图 - 错误：
<fieldset><input><legend>支付方式</legend></fieldset>→ 大部分辅助技术不识别，Chrome DevTools 的无障碍树中无组名 - 正确：
<fieldset><legend>收货信息</legend><input name="addr"></fieldset>，哪怕legend文本为空，也得保留标签结构
最常被忽略的一点：很多 UI 框架（如 Ant Design、Element Plus）的表单组件会自动剥离 fieldset 和 legend，只留 div 模拟结构。上线前一定要检查渲染后的 DOM，确认 fieldset 和其首个子节点 legend 真实存在且未被框架脚本过滤掉。
