多级表单应使用 fieldset + disabled/required 原生控制步骤激活与校验，禁用非当前组以避免提前校验；用 :user-invalid 和 button type="button" 分步校验，最后一步才 submit。
用 disabled 和 required 控制多级表单的显隐与提交流
多级表单不是靠 JS 拼 DOM 实现“分步”，而是让浏览器原生理解哪一步该激活、哪一步还不能填。核心是：禁用后续字段，直到当前步骤验证通过。
常见错误是只做 CSS 隐藏（display: none），但隐藏的 input 仍参与表单校验，提交时可能报错或漏数据。正确做法是结合 disabled + required 动态切换：
-
disabled让字段不接收输入、不参与提交、不触发required校验 - 当上一级通过（如选中某个
radio或填完邮箱），用 JS 移除对应下一级fieldset的disabled属性 - 仅对当前激活的字段组保留
required，其他组移除——避免浏览器提前报错
示例：二级地址选择中，省下拉启用后才启用市下拉，且市字段只有在省有值时才设 required。
用 fieldset + legend 管理逻辑分组和可访问性
不用 div 套 div 模拟步骤，直接用语义化 fieldset。它天然支持 disabled 批量控制内部所有控件，且屏幕阅读器会把 legend 当作该组标题朗读。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑是忘记给每个 fieldset 配 legend，导致无障碍支持断裂；或把 legend 写成纯文本而没用标签包裹，使 disabled 失效（部分浏览器中 legend 不受父级 disabled 影响）。
实操建议：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 每级表单用一个
fieldset，legend文本明确表达当前步骤目的（如“确认收货地址”） - JS 切换步骤时，只操作
fieldset的disabled属性，不要手动遍历子元素 - 若需视觉隐藏某组但保留可访问性（如初始未激活的步骤），用
aria-hidden="true"+tabindex="-1"，而非display: none
用 :valid 和 :invalid CSS 伪类驱动状态反馈
不必等 JS 监听 change 或 input 再加 class，浏览器原生支持基于表单验证状态的样式响应。这对多级表单的“下一步”按钮是否可点击特别有用。
关键点在于：这些伪类只在字段有 required 且值符合规则时生效；空的 required 字段默认为 :invalid，但一旦用户聚焦又离开（blur），才会触发校验提示。
推荐写法：
- “下一步”按钮初始设为
disabled，并绑定到当前fieldset内所有required字段是否都:valid - 用
fieldset:has(input:valid)（需检查浏览器支持）或更稳妥的 JS 监听input事件后调用checkValidity() - 避免依赖
:invalid显示红色边框——用户还没输就红，体验差；改用:user-invalid（Chrome 102+ 支持），只在用户交互后才生效
避免用 form 的 submit 事件处理多级提交逻辑
整个表单只有一个 form 标签没问题，但别在顶层 submit 事件里写一堆 if-else 判断当前在哪一步。这会让验证逻辑和 DOM 结构耦合过紧，调试困难。
更轻量的做法是：每级 fieldset 内放一个 button type="button" 作为“下一步”，用 JS 显式校验当前组，通过则 scrollIntoView 并启用下一组；最后一步的按钮才设为 type="submit"。
这样做的好处：
- 提交动作和验证范围一一对应，不会因某字段漏加
required导致整表单跳过校验 - 用户点击“上一步”时，只需
disabled当前组、启用上一组，无需重置整个表单 - 服务端接收时，仍是一个完整
FormData，不用拼接多个请求
真正麻烦的是跨步骤的联动校验（比如第二步的选项要根据第一步的值过滤），这种必须用 JS 维护状态，HTML 属性只能管住基础流程。
