URL参数最直接但需编码和限长；sessionStorage适合复杂数据但需及时清除；跨域必须用postMessage并校验origin；localStorage易致数据残留，应避免用于页面传值。
用 URL 参数传值最直接，但要注意编码和长度限制
浏览器地址栏能传的只有字符串，所有值都得变成 key=value 拼在 URL 后面。比如跳转到 detail.html?id=123&name=%E5%BC%A0%E4%B8%89，其中中文必须用 encodeURIComponent() 编码，否则会乱码或截断。
常见错误是直接拼接：url + '?name=' + userName —— 如果 userName 是 “张三&李四”，结果 URL 里会出现两个 &，第二个参数就被吞了。
- 用
URLSearchParams构造更安全：const params = new URLSearchParams({ id: 123, name: '张三' });<br>location.href = 'detail.html?' + params.toString(); - 单个参数不超过 2KB 比较稳妥；超长内容（如大段文本）别走 URL，改用
sessionStorage配合跳转 - IE11 不支持
URLSearchParams，需要 polyfill 或手动拼接 +encodeURIComponent
用 sessionStorage 传复杂数据，但要小心生命周期
sessionStorage 是页面会话级的临时存储，适合传对象、数组甚至 JSON 字符串，而且不暴露在 URL 里，比 URL 参数更干净。
典型误用是：在 A 页面存完就立刻跳转，B 页面在 DOMContentLoaded 里读 —— 看似没问题，但如果 B 页面加载慢，或者用户手抖多刷了一次，sessionStorage 就空了。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- A 页面写入时加时间戳或唯一标识：
sessionStorage.setItem('detailData', JSON.stringify({ id: 123, tags: ['vue', 'bug'] })); - B 页面读取后立即清除：
const data = sessionStorage.getItem('detailData');<br>if (data) {<br> const obj = JSON.parse(data);<br> sessionStorage.removeItem('detailData'); // 关键！防重复读<br>} - 注意：新开标签页、iframe、或从书签打开的页面，拿不到上一个页面的
sessionStorage
跨域场景下不能用 URL 或 sessionStorage，得靠 postMessage
如果目标网页是不同源的（比如 https://a.com 跳到 https://b.com），URL 参数能传，但 sessionStorage 完全隔离，连读都读不到。
这时候只能让两个页面主动通信：postMessage 是唯一通用方案，但必须双方配合，且要校验来源。
- A 页面发消息前确认目标窗口已存在：
const popup = window.open('https://b.com/receive.html');<br>popup.postMessage({ userId: 456, token: 'abc123' }, 'https://b.com'); - B 页面监听时必须检查
event.origin：window.addEventListener('message', e => {<br> if (e.origin !== 'https://a.com') return;<br> console.log(e.data); // { userId: 456, token: 'abc123' }<br>}); - 不校验
origin是严重安全隐患，恶意站点可伪造消息
别用 localStorage 做页面间传值，除非你明确要持久化
有人图省事把数据塞进 localStorage，想着“反正能跨页面读”。但问题在于：它不会自动清理。用户下次再点同一个链接，拿到的可能是上次残留的旧数据。
更麻烦的是调试困难 —— 你改了代码，但本地存的旧值还在，表现不一致，容易误判 bug 在哪。
- 如果真要用，务必加命名空间和过期时间：
const payload = { data: { id: 789 }, timestamp: Date.now() };<br>localStorage.setItem('myapp:detail:202405', JSON.stringify(payload)); - 读取时先判断时间戳是否过期（比如 5 分钟内有效）
- 绝大多数情况下，不如老实用
sessionStorage+ 清除逻辑，更可控
真正难的不是怎么传，而是怎么确保对方一定能收到、且只收一次。URL 容易被截断，sessionStorage 容易被刷掉，postMessage 容易被冒充 —— 所有方案都要补一层“防御性读取”逻辑，而不是写完 setItem 就以为结束了。
