history.pushState 本身不卡顿，瓶颈在于后续 DOM 操作或同步序列化；popstate 需早期监听且 URL 同源；DOM 还原须调用编辑器原生方法并恢复额外状态；history.state 刷新后为空属正常，需用 localStorage 持久化。
history.pushState 频繁调用会导致卡顿吗
不会直接卡顿，但若每次 pushState 都伴随大量 DOM 操作或未节流的快照序列化（比如 JSON.stringify(editor.getValue())），就会明显拖慢。浏览器本身对历史栈操作是轻量的，瓶颈永远在你的回调逻辑里。
- 每调用一次
pushState，浏览器只存你传入的state对象和 URL，不执行渲染、不 diff DOM - 真正耗时的是你通常跟在它后面的那句：比如
document.body.innerHTML = newHtml或重绘编辑器画布 - 如果用
localStorage同步写入版本快照，注意localStorage.setItem是同步阻塞操作，高频调用会卡主线程 - 建议把快照逻辑移进
setTimeout或requestIdleCallback，尤其当编辑器内容超过 10KB 时
popstate 事件监听没响应？检查这三点
popstate 不触发，90% 是因为没注册监听，或注册时机错了——它不像 load 那样可反复绑定，必须在页面初始化阶段就挂上。
- 监听必须写在
<script></script>内或DOMContentLoaded回调中，不能等用户点“保存”才去window.addEventListener('popstate', ...) -
state为空（null）很常见：要么当初pushState(null, '', url)传了null，要么用户从地址栏手动刷新/跳转进来，此时没有关联 state - 确保 URL 是同源且可解析的；
file://协议下所有historyAPI 均静默失败，连错误都不抛
回溯时 DOM 状态丢失？别用 innerHTML 直接替换
单纯把快照 HTML 字符串赋给 innerHTML，会清空所有已绑定的事件、销毁富文本编辑器实例、断开 Web Component 生命周期——看起来“还原了”，实则交互全失效。
- 可视化编辑器（如 GrapesJS）必须调用其原生方法还原，例如
editor.setComponents(htmlString)+editor.setStyle(cssString) - 若预览区用
iframe隔离，还原时得用iframe.contentDocument.write(html)，再重新注入 runtime 脚本（否则按钮没点击效果） - 自己维护的状态（如当前选中组件、光标位置）不能只靠 HTML 快照，得额外存进
state对象里，popstate触发后一并恢复
localStorage 记录访问时间线，但页面刷新后 history.state 为空怎么办
这是设计使然，不是 bug。history.state 只在通过 pushState/replaceState 或 go() 跳转时才有值；直接刷新或输入 URL 进来，state 就是 null。想持久化访问痕迹，得靠你自己记。
- 每次页面加载（包括刷新）都执行：
localStorage.setItem('lastVisit', Date.now().toString()) - 不要依赖
history.length判断是否“有历史”，它只返回可前进/后退步数，和实际 URL 无关 - 若需跨标签页共享访问记录，用
localStorage；仅当前 tab 有效，用sessionStorage - 注意：
localStorage存满（通常 5–10MB）会静默失败，建议加 try/catch 并 fallback 到内存数组
真正容易被忽略的点是：**history API 本身不保存任何 UI 状态，它只是个导航协调器。所有“回溯像原样”的体验，都来自你主动存、主动取、主动还原的三步闭环。少走一步，用户点“上一版”就只剩一个空壳页面。**
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
