history.state 不保存表单数据，popstate 仅通知url和state变更，需手动还原表单值；应存最小可序列化状态、严格对齐字段名、区分pushstate/replacestate时机，并在初始化时统一处理非popstate入口。
history.state 本身不保存表单数据，popstate 也不触发页面重载——想靠它“自动回滚多级表单”，直接踩进浏览器历史机制的认知误区。
为什么 popstate 不会帮你恢复表单值
浏览器在触发 popstate 事件时，只还原 URL 和 history.state 对象，完全不操作 DOM 或表单控件的 value 属性。你看到表单“没变”，不是它记住了，而是没人去设回去。
-
popstate是被动通知，不是恢复指令 -
history.state是纯 JS 对象，存什么、怎么用全由你决定 - 用户点后退按钮 → 触发
popstate→ 你必须手动读history.state→ 手动 set 表单字段
如何设计可回滚的 state 结构
别存整个表单 DOM 或函数引用，只存能序列化、可预测、带版本标识的最小必要状态。比如三级地址选择器：
const state = {
step: 'city',
formData: {
province: 'zhejiang',
city: 'hangzhou',
district: 'xihu'
},
timestamp: Date.now()
};
- 必须包含当前步骤标识（如
step），否则无法判断该渲染哪一级 -
formData字段名要和表单控件name或 ref 严格对齐，避免映射错位 - 避免存
Date实例、RegExp、undefined——history.pushState()会静默丢弃它们 - 如果表单有异步校验状态（如手机号是否已注册），不要塞进
history.state，它不该承担副作用缓存职责
pushState + replaceState 的使用时机
不是每输一个字都要 push，也不是所有跳转都该用 push。关键看是否产生新的、可独立访问的历史节点：
- 用户从「省份」选到「城市」→ 用
pushState()，生成新历史项 - 用户修改「城市」选项但未提交 → 用
replaceState()，覆盖当前项，避免后退时卡在中间无效态 - 点击「上一步」回到前一级 → 先
history.back()，再在popstate里还原 UI；不要自己维护栈数组模拟 - 表单提交成功后跳转结果页 → 必须用
replaceState()清掉整个多级流程的 history，否则用户刷新会重新进入未完成表单
自愈逻辑必须覆盖非 popstate 入口
用户可能直接输入 URL、刷新页面、或从书签打开某一级地址。此时 popstate 根本不触发，但你要让页面“看起来像刚从 history 回来”：
- 在组件初始化时（如 React 的
useEffect、Vue 的onMounted）立即检查history.state - 如果
history.state存在且结构合法，直接执行还原逻辑（和popstate里复用同一套函数） - 如果
history.state为空或损坏，降级为默认初始态，不要抛错或白屏 - 注意：服务端渲染（SSR）场景下，首屏 JS 还没执行，
history.state在客户端才可用，服务端无法预取
真正难的不是写几行 pushState，而是把“用户行为流”和“history 栈生命周期”对齐——比如取消按钮该 go(-2) 还是 replaceState，取决于你是否允许用户再退一次回到取消前。这些细节不会报错，但会让回滚体验断层。
