最常见原因是父页未校验event.origin。必须只接受可信域名如https://pay.alipay.com，且校验逻辑须在回调内；iframe需满足allowpaymentrequest="true"、HTTPS src、父页为安全上下文；支付页跳转前应发最终状态消息；禁用sandbox="allow-same-origin"；父页须等待iframe加载完成再发消息。
postMessage 事件监听没加 origin 校验
收到支付页发来的消息却没响应，最常见原因是父页的 window.addEventListener("message", handler) 没做来源验证。浏览器允许任意域名向你发消息，不校验 event.origin 就直接处理，等于把回调入口敞开给所有网站。
必须只接受已知可信域名，比如：
-
https://pay.alipay.com、https://wx.tenpay.com这类明确白名单，不能用"*" - 校验逻辑要写在事件回调内部，不能靠外部变量或延迟判断
- 收到成功消息后立即调用
window.removeEventListener("message", handler)，防止重复触发
iframe 的 allowpaymentrequest="true" 配置无效
内嵌页面调用 PaymentRequest.show() 报 SecurityError: Permission denied，不是 JS 写错了，而是 iframe 标签本身没通过安全准入。
三个硬性条件缺一不可：
立即学习“前端免费学习笔记（深入）”；
-
allowpaymentrequest属性值必须是字符串"true"—— 写成allowpaymentrequest（布尔属性）、allowpaymentrequest="1"或空值都无效 -
src必须是 HTTPS 协议；HTTP 或srcdoc场景下该属性静默失效 - 父页面必须运行在安全上下文：仅
https://或localhost（注意：http://127.0.0.1不行）
调试时可在 iframe 内控制台执行 window.isSecureContext，确认是否为 true。
支付页跳转导致 postMessage 中断
用户点击“确认支付”后，第三方页面发生跳转（如从收银台跳到结果页），这时原页面的 JS 上下文被销毁，之前注册的 postMessage 发送逻辑就丢了。
这不是父页的问题，而是支付页自身实现缺陷。应对方式有：
- 要求支付方在跳转前主动发一次最终状态消息，比如
{type: "payment-final", status: "success", order_id: "abc123"} - 若无法协调，父页改用轮询订单接口 + 本地存储标记（如
localStorage.setItem("pending_order", "abc123")）兜底 - 避免依赖跳转后的 URL 参数回传结果，因为 iOS Safari 和部分 WebView 会拦截或丢弃 query string
sandbox 属性误开 allow-same-origin 导致通信失败
为了“方便调试”加了 sandbox="allow-scripts allow-same-origin"，结果反而让 postMessage 失效——这不是 bug，是浏览器故意设计的行为。
当启用 allow-same-origin 且 iframe 跨域时，浏览器会拒绝建立跨域通信通道，postMessage 调用不报错但对方收不到。真实生产环境必须去掉它：
- 正确配置应为
sandbox="allow-scripts allow-popups allow-forms" - 通信全部走
postMessage，不依赖 DOM 访问或共享上下文 - 如果真需 cookie 共享，请用
document.domain配合后端Set-Cookie Domain设置，而非开放沙箱
最易被忽略的一点：支付页加载后，父页必须等 iframe.onload 或 iframe.contentWindow 可访问再发初始化消息，否则消息发出去就石沉大海。
