HTML本身不提供组件状态持久化能力，所有“记住用户操作”行为必须由开发者显式编码实现；localStorage是最常用载体，关键在于存什么、何时存、如何恢复。
HTML 本身不提供组件状态持久化能力，所有“记住用户操作”的行为都必须由开发者显式编码实现；localStorage 是最常用且够用的载体，但关键在于存什么、什么时候存、怎么恢复。
哪些状态必须手动存，哪些可以忽略
不是所有 DOM 状态都需要持久化。真正值得存的，是用户主动产生的、有业务意义的标识或值：
-
input.value、textarea.value、select.selectedIndex、checkbox.checked—— 表单类状态，直接映射用户输入 -
details.hasAttribute('open')—— 折叠/展开状态，用data-id关联存储键名 - 自定义组件的
data-expanded、data-active-tab等宿主属性 —— 避免把状态藏在 shadowRoot 内部 - 拖拽看板中各列的卡片 ID 数组，如
{"todo": ["task-1"], "done": ["task-2"]}—— 不存 DOM 结构，只存归属关系
以下状态通常无需存：scrollTop（除非是长列表/日历等强感知场景）、focus（浏览器自动聚焦不可靠，且易被覆盖）、style.left 或 class（应由状态驱动，而非反向推导）。
localStorage 存取的实操要点
localStorage 只存字符串，所以必须做序列化和类型校验，否则恢复时会出错：
立即学习“前端免费学习笔记（深入）”；
- 存的时候用
JSON.stringify()，读的时候用JSON.parse()，并加try/catch—— 否则 localStorage 被手动清空或数据损坏会导致整个脚本中断 - 不要存整个
document.getElementById('form').innerHTML—— 一旦 DOM 结构微调（比如加个 class 或改个事件绑定方式），解析后渲染就会失败 - 键名要带业务前缀，比如
'user-form-draft'而不是'data'，避免跨页面冲突 - 恢复时机很重要：不能在
connectedCallback或DOMContentLoaded立即读取并设置shadowRoot.innerHTML—— 此时 DOM 尚未就绪，应延迟到requestAnimationFrame或setTimeout(() => {}, 0)
Shadow DOM 组件的状态陷阱
在 mode: 'open' 的 Shadow DOM 中，shadowRoot.innerHTML = ... 会销毁全部节点，导致 input.value、滚动位置、焦点全部丢失：
- 禁止在
attributeChangedCallback里直接重写shadowRoot.innerHTML—— 用户正在输入时父组件改了个无关属性，输入框就清空了 - 改用
DocumentFragment或lit-html render()做局部更新，只替换变化的部分 - 如果用了
mode: 'closed'，this.shadowRoot返回null，调试时看不到内部结构，也不便于用querySelector检查状态 —— 开发阶段建议始终用'open' - 所有关键状态必须同步到宿主元素的属性上，例如
this.setAttribute('data-checked', 'true')，再由宿主自己决定是否写入localStorage
动态组件切换时的状态保留边界
Vue 的 <keep-alive> 或 React 的 useState 只管 JS 层状态，不保证 DOM 行为持续有效：
-
<keep-alive>会让组件跳过unmounted，但setInterval、addEventListener、echarts.init()创建的实例不会自动清理 —— 必须在beforeUnmount或deactivated里手动clearInterval和dispose() -
v-show虽然保留 DOM，但所有组件常驻内存，适合最多 2–3 个轻量组件；更多组件建议用v-if+localStorage恢复关键状态 - 第三方库（如地图、图表）初始化后生成的上下文、Canvas、Worker 实例，无法被序列化，只能在恢复时重新创建 —— 所以 localStorage 只存配置参数，不存实例引用
真正难的不是“怎么存”，而是判断哪些状态值得存、哪些恢复成本高于收益；一个 checkbox 的勾选状态存一次就够了，而一个拖拽布局的坐标和层级关系，就得设计成可增量更新的结构。
