使用window.dispatchEvent替代postMessage在内容脚本传讯的弊端探讨

安全层面风险 #

• 无内置 origin 校验：postMessage 提供 targetOrigin 参数，可精准限制消息接收方的域名，有效防止敏感数据被恶意页面窃取。而 CustomEvent 没有这类原生校验机制，任何监听该自定义事件的页面脚本都能接收数据，若传递的是敏感信息（如扩展操作数据），极易被恶意脚本拦截。
• 事件易被监听：自定义事件的名称由开发者定义，恶意脚本可通过猜测或遍历常见名称提前监听，获取传递的数据。相比之下，postMessage 的消息需监听 message 事件，接收方可通过判断 event.origin 过滤非法来源，安全性更高。

功能层面限制 #

• 兼容性隐患：尽管现代浏览器大多支持 CustomEvent 在内容脚本与页面脚本间通信，但部分旧版浏览器（如早期Chrome、Firefox）可能存在上下文隔离的兼容性问题。而 postMessage 是浏览器标准跨上下文通信API，兼容性经过长期验证，稳定可靠。
• 数据传递局限性：postMessage 会自动序列化复杂数据（如对象、数组），确保跨上下文传递的正确性。CustomEvent 的 detail 字段传递复杂数据时，在浏览器Site Isolation等严格隔离场景下，可能出现序列化失败或数据丢失的问题。
• 无法跨窗口/iframe通信：postMessage 支持跨窗口、跨iframe传递消息，后续扩展功能时无需额外改造。而 dispatchEvent 仅能在当前窗口上下文内传递，无法实现跨窗口/iframe的通信需求，扩展性不足。

总结 #

若仅需在当前页面传递非敏感的简单数据，dispatchEvent 可能暂时可用，但从安全防护和功能扩展性角度，postMessage 是更稳妥的选择——这也是Chrome与MDN文档优先推荐它的核心原因。

内容的提问来源于stack exchange，提问作者aryzing