根本原因是状态失控而非DOM切分；必须用统一JS对象集中管理所有字段值，禁止直接操作input.value，所有写入需经updateField等封装函数，并在提交前手动构造FormData合并多表单数据。
大表单拆分后数据不一致，根本原因不是DOM切分而是状态失控
表单拆分后用户填到一半跳转、上一步改值下一步没同步，问题不在“怎么切HTML”，而在状态没集中管理。浏览器原生 form 元素只管自己范围内的字段，跨表单时 FormData 对象不会自动合并，formdata 事件也监听不到其他区域的输入。
必须用一个 JS 对象（比如 formData）统一存所有字段值，每个子表单只读写其中一部分键：
- 禁止直接操作
input.value后不更新状态对象；所有写入必须走updateField(name, value)这类封装函数 - 如果用
localStorage持久化中间状态，监听beforeunload即可，别在每次input事件里写入——性能差，且容易存入未校验的脏值 - 跨步骤验证（如“密码”和“确认密码”不在同一屏）必须在最终提交前汇总校验，不能依赖单个
<form></form>的checkValidity()
多个 <form> 如何合并提交：唯一可靠路径是手动构造 FormData
浏览器原生不支持跨 <form> 提交。多次调用 form.submit() 会覆盖请求体，完全不可靠。
正确做法是用 new FormData() 初始化，再逐个 append() 字段：
立即学习“前端免费学习笔记（深入）”；
const formData = new FormData();
formData.append('user[email]', emailInput.value);
formData.append('user[phone]', phoneInput.value);
注意几个关键点：
- 文件上传必须用
fileInput.files[0]获取真实File对象，不能用fileInput.value（现代浏览器已禁用该值，且它只是路径字符串） - 字段名冲突要提前约定策略，例如重复出现的
utm_source以最后一步为准，或在append()前抛出警告 - 不要试图监听每个子表单的
formdata事件——它只对当前<form>有效，且不带上下文标识，无法判断“现在该提交哪几步”
用 <fieldset> + disabled 模拟分步 vs 真路由跳转：选错场景会埋坑
两种方式适用边界非常明确，混用会导致状态丢失、前进后退失效等问题。
-
<fieldset disabled>适合纯前端、无服务端状态依赖的轻量流程（如注册向导），好处是 DOM 不销毁、输入值天然保留，但无法做服务端校验或权限控制 - 真路由跳转（配合
useNavigate）适合需服务端校验、权限控制或 SEO 的场景（如多步订单），但必须主动 restore 输入值——否则浏览器前进/后退时，input值会清空 - 如果选了路由跳转，
beforeunload+localStorage是保底方案，但更健壮的做法是在路由切换前把当前步数据 commit 到集中状态对象，并在新页面 mount 时从该对象初始化表单控件
为什么放弃 formdata 事件、改用显式函数调用更可控
formdata 事件本质是原生表单的副产物，它解决不了拆分场景的核心问题：
- 它只触发于挂载在 DOM 上的
<form>元素，对动态插入的select或异步加载的字段无效——那些控件可能还没挂载，事件就已触发 - 即使你在每个子表单都监听该事件，也无法知道“此刻用户正在提交第几步”，事件本身不带任何上下文标识
- 真正省事的方式反而是显式调用类似
serializeStep(2)的函数：逻辑清晰、可 debug、可加日志、可拦截、可复用
复杂点在于字段命名空间和生命周期管理——比如某步被销毁又重建，它的控件引用是否还有效？updateField 是否仍能准确映射到状态对象？这些细节比“怎么切HTML”更容易被忽略。
