allowpaymentrequest属性必须显式设为"true"字符串值才生效，且仅当iframe的src为HTTPS、父页面为安全上下文（https://或localhost）、无srcdoc时有效；其他写法及HTTP环境均静默失败。
allowpaymentrequest 属性必须显式设为 "true"
默认情况下，<iframe></iframe> 会禁用 PaymentRequest API，即使内嵌页面调用 new PaymentRequest(...) 也会直接抛出 SecurityError: Permission denied。关键不是加属性就行，而是值必须是字符串 "true" —— 写成 allowpaymentrequest（布尔属性写法）、allowpaymentrequest="1" 或 allowpaymentrequest="" 都无效。
正确写法只有这一种：
<iframe src="https://example.com/checkout.html" allowpaymentrequest="true"></iframe>
- 该属性不继承父页面的支付权限，必须在 iframe 标签上单独声明
- 仅当 iframe 的
src是 HTTPS 协议时才可能生效（HTTP 下即使设了也静默失败） - 若 iframe 使用
srcdoc，则该属性被忽略（srcdoc内容被视为 data URL，不支持支付请求）
父页面需满足 Secure Context 要求
allowpaymentrequest="true" 只是“放行开关”，但开关能打开的前提是整个上下文可信。父页面必须运行在 https:// 或 localhost 环境下 —— 任何 http:// 页面（包括 127.0.0.1 非 localhost）都会让该属性失效，且控制台通常不报错，只在调用 paymentRequest.show() 时静默拒绝。
- 开发阶段可用
localhost:3000测试，但http://127.0.0.1:3000不行 - 若父页通过
iframe嵌入子页，而子页本身又嵌了第三方支付 SDK，那子页的PaymentRequest调用仍受父页上下文约束 - 可通过
window.isSecureContext在父页和 iframe 内分别检查是否满足条件
iframe 内页面调用 PaymentRequest 的注意事项
即使属性和上下文都正确，内嵌页面仍可能因跨域或配置问题失败。常见卡点：
立即学习“前端免费学习笔记（深入）”；
-
PaymentRequest构造时传入的methodData中，supportedMethods必须包含浏览器实际支持的支付方式（如"basic-card"），不能只写"https://apple.com/apple-pay"却没装 Apple Pay 插件 - 若 iframe 的
src与父页不同源，内嵌页面无法访问父页的top.document，但PaymentRequest本身不要求跨域访问，只要 iframe 自身满足条件即可 - 某些浏览器（如 Safari 16.4+）对 iframe 中的
PaymentRequest有额外限制：要求用户已与 iframe 有过交互（例如点击过按钮），否则.show()调用会被拒绝
调试时怎么看是否生效
最直接的办法是在 iframe 内页面的控制台执行：
console.log('PaymentRequest' in window); // 应为 true<br>try {<br> new PaymentRequest([{supportedMethods: ['basic-card']}], {});<br> console.log('PaymentRequest constructor OK');<br>} catch (e) {<br> console.error(e.message); // 若是 "Permission denied"，大概率是 allowpaymentrequest 没生效或上下文不安全<br>}
如果构造函数能成功创建实例，但 .show() 报错，重点检查：window.isSecureContext、用户是否触发过交互、支付方法是否被当前浏览器支持。别漏掉 iOS 上 Safari 对 iframe 支付的特殊拦截逻辑 —— 它有时连错误都不抛，只是黑屏或无响应。
