HTML5无内置多标签页通信加密机制，需开发者结合BroadcastChannel/Web Crypto API、postMessage/iframe或SharedWorker/IndexedDB自行实现加解密；密钥须安全生成与存储，严禁硬编码或明文保存。
HTML5 本身不提供内置的“多标签页通信加密”机制，但可以通过 localStorage、sessionStorage、BroadcastChannel、SharedWorker 或 postMessage（配合 iframe）实现跨标签页通信；所谓“加密”，需由开发者在数据传输前自行加解密，不能依赖浏览器自动完成。
使用 BroadcastChannel + Web Crypto API 加密通信
BroadcastChannel 是最轻量、现代且专为同源多标签页通信设计的 API。它不自动加密，但可结合浏览器原生的 Web Crypto API 对消息内容加密后再发送：
- 在发送端：用
crypto.subtle.encrypt()对明文（如 JSON 字符串）进行 AES-GCM 加密，生成密文和 IV，连同密文一起广播 - 在接收端：用相同密钥和 IV 调用
crypto.subtle.decrypt()还原数据 - 密钥建议通过
crypto.subtle.generateKey()在首次加载时生成并安全存储于sessionStorage（避免跨会话复用），或由后端下发短期有效的对称密钥 - 注意：
BroadcastChannel不支持跨域，且 IE 完全不支持，需检查兼容性（Chrome 64+、Firefox 61+、Edge 79+）
用 postMessage + iframe 中转实现可控加密通信
当需要更细粒度控制（如指定目标窗口、跨子域通信），可用隐藏 iframe 作为中转枢纽，配合 postMessage 和自定义加解密逻辑：
- 所有标签页向同一个同源 iframe（如
/bridge.html）发送加密后的消息，iframe 统一解密、验证、再按规则分发 - 加密可采用 AES-CBC（需填充）或更推荐的 AES-GCM（带认证），密钥通过
localStorage协商或登录态派生（如用用户 token + salt 生成 HKDF 密钥） - 务必校验消息来源（
event.origin）、设置有效时间戳（防重放）、添加简单签名（如 HMAC-SHA256）防止篡改 - iframe 模式兼容性好（IE8+ 支持），但增加 DOM 节点和通信链路，需注意性能与清理逻辑
SharedWorker + IndexedDB 实现带权限的加密状态同步
适合需持久化、多页共享敏感状态（如登录凭证缓存、临时令牌）的场景：
立即学习“前端免费学习笔记（深入）”；
- 创建
SharedWorker作为中心服务，各标签页通过port.postMessage()与其通信 - Worker 内部使用
IndexedDB存储加密后的数据块（如用 RSA-OAEP 加密 AES 密钥，再用该 AES 密钥加密业务数据） - 读写操作均由 Worker 统一处理，可加入访问控制（如校验 tab ID、会话有效期、请求签名）
- 注意：SharedWorker 在 Safari 中支持有限（仅 macOS/iOS 16.4+），移动端兼容需谨慎评估
关键安全提醒：加密不是万能，设计比算法更重要
即使用了 AES-256，若密钥管理不当或上下文缺失，仍可能被绕过：
- 禁止将密钥硬编码在 JS 中，也不应直接存在
localStorage明文字段里；优先用sessionStorage+ 页面生命周期绑定，或内存变量（如闭包中的const key） - 避免用
Math.random()生成密钥——必须使用crypto.getRandomValues() - 不要试图“加密 localStorage 本身”——浏览器不提供钩子；只能对存入前的数据加密，读取后解密
- 如果通信内容涉及身份、支付等高敏信息，多标签页通信应尽量规避，改用服务端统一状态管理（如 WebSocket 长连接 + session 绑定）
