localStorage是HTML模板跨页面通信的默认选择，因其是同源下唯一无需后端、不依赖跳转、能自动跨标签页读写的持久化机制，关浏览器再开也不丢数据，且对多页表单等场景够用稳定无侵入。
localStorage 为什么是 HTML 模板跨页面通信的默认选择
因为它是同源下唯一无需后端、不依赖跳转、能自动跨标签页读写的持久化机制。只要两个 HTML 页面跑在同一个协议+域名+端口下，localStorage 就能直接共享数据，且关掉浏览器再打开也不丢。
它不是“最强大”的方案，但对模板类场景（比如多页表单、组件化页面、静态内容预填充）来说，够用、稳定、无侵入。其他方案要么要开新窗口（postMessage）、要么只支持当前会话（sessionStorage）、要么需要服务端配合（URL 参数 + 后端路由）。
-
localStorage的键名必须统一约定，比如都用"template-form-data"，否则各页面写各自的 key，根本读不到 - 存对象必须用
JSON.stringify()，取出来必须用JSON.parse()，否则拿到的是字符串"[object Object]" - 如果模板里用了富文本编辑器（如 TinyMCE），直接存
innerHTML可能含 script 标签，需提前过滤 XSS —— 不是localStorage的问题，是你的数据没净化
如何避免 localStorage 在跨页面时“读不到”或“读旧值”
常见现象：A 页面改了数据，B 页面刷新后才看到；或者 B 页面始终读到空值。根本原因不是 API 失效，而是时机或监听缺失。
- 写入后不能立刻在另一页面读取 ——
localStorage是异步持久化的，但实际延迟可忽略；真正问题是 B 页面可能已经加载完毕，而 A 页面还没写完 - 必须在 B 页面加
window.addEventListener("storage", handler)才能实时响应变化，光靠getItem只能读初始值 - 监听函数里要检查
e.key === "your-key-name"，否则会收到其他 key 的变更（比如广告脚本写的） - 如果 B 页面是通过
location.reload()刷新的，那 storage 事件不会触发 —— 它只在**其他标签页**修改时广播，当前页改自己不会触发自身监听
localStorage + BroadcastChannel 组合解决“实时同步延迟”
单靠 localStorage 无法通知“当前页数据已更新”，只能等用户刷新或手动轮询。加上 BroadcastChannel 就能实现真正的跨标签页秒级同步，尤其适合模板中多个页面同时编辑同一份配置的场景。
立即学习“前端免费学习笔记（深入）”；
- 先写
localStorage.setItem("config", JSON.stringify(data)) - 再发广播：
bc.postMessage({ type: "CONFIG_UPDATE", data })，其中bc = new BroadcastChannel("template-channel") - 所有监听页收到消息后，可立即更新 DOM，不必等 storage 事件（它有约 50–100ms 延迟）
- 注意：Safari 对
BroadcastChannel支持从 v14.1 开始，旧版 iOS 需降级 fallback 到轮询localStorage
模板中哪些数据不该往 localStorage 里塞
不是所有东西都适合塞进 localStorage。模板常含动态结构，容易踩坑：
- DOM 节点引用（
document.getElementById("xxx")）—— 存进去是[object HTMLElement]，取出来啥也不是 - 函数、Date 对象、RegExp ——
JSON.stringify()会丢掉它们，变成null或空对象 - 超大 HTML 字符串（比如整页渲染结果）—— 虽然理论上支持 5–10MB，但写入/读取变慢，且可能触发浏览器内存警告
- 敏感字段（token、密码、身份证号）——
localStorage可被任意同源 JS 读取，XSS 一挂全暴露
真正该存的，是模板需要复用的“纯数据”：表单项值、用户偏好开关、选中的主题色、分步表单的中间状态 —— 这些才是 localStorage 设计的本意。
