前端页面传参：选对方法，避开那些“坑”
在前端开发中，页面间如何高效、安全地传递参数是一个核心问题。直接给出结论：**URL查询字符串（Query String）** 是最常见的方式，但存在长度限制与安全隐患；**`sessionStorage`** 则适合传递结构化的对象数据，且不会暴露在地址栏；而当遇到**跨域**场景时，**`postMessage`** 是唯一可靠的解决方案，不应再尝试用URL强行传递。
用 URLSearchParams 拼接参数，告别手动编码的烦恼
过去，开发者常手动拼接URL字符串，例如 `url + '?id=' + id + '&name=' + name`。这种做法风险极高：若参数值本身包含 `&` 或空格等特殊字符，会破坏参数结构；中文字符不编码则直接显示为乱码。现代浏览器提供的 **`URLSearchParams` API** 能完美解决这些问题，它自动处理编码与格式：
const params = new URLSearchParams({ id: 123, name: '张三', tags: ['a', 'b'] });—— 数组参数会自动转换为 `tags=a&tags=b` 的格式。location.href = 'detail.html?' + params.toString();—— 安全生成URL，无需再手动调用 `encodeURIComponent`。- 需注意兼容性：IE11不支持此API，老项目需引入polyfill。对于旧代码，建议封装兼容函数，但绝对不要自己写正则表达式去解析 `location.search`，极易出错。
- 最后提醒：URL参数总长度建议控制在浏览器限制内（通常约2KB），超长内容（如富文本）应选择其他方式传递。
sessionStorage 传对象，比URL更干净利落
当需要传递如 `{ userId: 1001, permissions: ['read', 'edit'], config: { theme: 'dark' } }` 这类复杂的JavaScript对象时，将其编码成URL会变得冗长且可读性差。此时，**`sessionStorage`** 提供了更优雅的方案：直接存储JSON字符串。
- 在源页面A：
sessionStorage.setItem('pageData', JSON.stringify(obj)); location.href = 'target.html'; - 在目标页面B：
const data = JSON.parse(sessionStorage.getItem('pageData') || '{}');—— **务必进行空值判断**，否则 `JSON.parse(null)` 会导致解析错误。 - 关键清理步骤：页面B成功读取数据后，应立即执行
sessionStorage.removeItem('pageData')。否则用户刷新页面时会重复读到旧数据，引发逻辑错误。 - 注意其会话特性：通过新标签页打开、从书签访问或通过iframe加载的页面，无法共享同一会话的 `sessionStorage`。
跨域页面传参，postMessage 是唯一选择
当从 `https://a.com/a.html` 跳转或打开 `https://b.com/b.html` 时，URL参数虽可携带，但 `sessionStorage`、`localStorage` 因同源策略限制完全隔离。此时，**`window.postMessage`** 是实现跨域通信的标准且安全的方法。
立即学习“前端免费学习笔记（深入）”；
- 发送方（A页面）需确保目标窗口已加载：
const win = window.open('https://b.com/b.html'); win.postMessage(data, 'https://b.com'); - 接收方（B页面）需设置事件监听：
window.addEventListener('message', e => { if (e.origin === 'https://a.com') { /* 安全处理 e.data */ } }); - **安全至关重要**：必须严格校验 `e.origin`，不能仅信任 `e.data`，以防止恶意网站伪造消息进行攻击。
- `postMessage` 是异步通信，发送后不能假定对方立即处理。同时，接收方应做好防抖或状态管理，避免同一消息被重复处理。
总结来说，选择哪种**前端页面传值方法**，关键在于匹配场景：传递简单标识（如ID）优先用URL；传递复杂表单或状态对象用 `sessionStorage`；而涉及**跨域页面传参**时，`postMessage` 是必经之路，其发送与接收逻辑需双方页面协同实现，缺一不可。
