HTML5无法直接调用iOS/Android原生内购接口，必须通过Hybrid桥接：iOS调用SKPaymentQueue、Android集成BillingClient，H5仅能通过约定JS接口触发原生支付流程。
HTML5 页面本身无法直接调用 iOS 或 Android 的原生内购（IAP）接口，所谓“HTML5 转 APP 做内购”，本质是 Hybrid 或 WebView 容器场景下的桥接问题——不是 HTML5 实现内购，而是宿主 App 提供 JS 接口，让 H5 触发原生支付流程。
WebView 中调用 storekit 或 billingclient 必须走原生桥接
纯 HTML5 没有访问设备支付能力的权限。iOS 上需调用 SKPaymentQueue，Android 上需集成 Google Play 的 BillingClient，这些都只能在原生层完成。H5 只能通过约定好的 JS 方法（如 window.webkit.messageHandlers.pay.postMessage(...) 或 AndroidBridge.buy(...)）通知原生端启动流程。
- 常见错误：在 H5 里直接引入第三方 JS SDK（如 Stripe、Alipay SDK）尝试唤起 App Store/Play Store 内购——完全无效，会静默失败或报
ReferenceError - 必须由打包后的 App 提供统一支付入口，例如暴露
window.payWithSKU全局函数，参数含sku、type（'ios'/'android'）、successCallback等 - iOS WKWebView 需提前在
WKUserContentController注册 handler；Android WebView 需调用addJavascriptInterface（注意 Android 4.2+ 仅带@JavascriptInterface注解的方法才可被调用）
restorePurchases 和 getProducts 为什么总返回空？
这两个操作高度依赖原生端是否已完成初始化和用户登录状态同步。H5 发起请求后，若原生层尚未完成 configure（iOS）或 startConnection（Android），就会无响应或返回空数组。
- iOS：确保
SKPaymentQueue.default().add(self)在 App 启动时已执行，且未被释放；Sandbox 测试账号必须登出系统级 App Store 账号再重新登录 - Android：
BillingClient初始化后必须等待onBillingSetupFinished回调成功，再调用querySkuDetailsAsync；SKU 列表必须与 Play Console 中的“管理应用内商品”完全一致（大小写、前缀、空格均敏感） - H5 不应自行缓存商品列表，每次进入购买页都应触发原生端重查——否则上线后新增商品不显示
沙箱测试失败的三个高频卡点
真机上跑通不代表能过审，沙箱环境比生产更脆弱，尤其对签名、Bundle ID、账号链路极其敏感。
立即学习“前端免费学习笔记（深入）”；
- iOS：测试账号必须是 Apple ID 新注册的 Sandbox 账号（不能用真实 Apple ID），且在设备「设置 → App Store」中退出当前账号，再用 Sandbox 账号登录；Xcode 归档包的 Bundle ID 必须与 App Store Connect 中配置的完全一致
- Android：测试账号需加入 Play Console 的「许可测试人员」列表，且该账号必须用 Chrome 访问 https://www.php.cn/link/016b388b5ee40f99cc161d3aeb35b545 并启用测试资格；
applicationId必须与 Play Console 中应用包名严格匹配 - 无论 iOS 还是 Android，H5 页面中的支付按钮点击后，若原生端没抛出明确错误（如
"product not found"或"billing not ready"），大概率是桥接未生效——检查 JS 调用时函数名拼写、参数类型（字符串 vs 对象）、回调注册时机
最易被忽略的是凭证校验环节：客户端完成支付后只传 receipt 给服务端，但苹果要求校验 receipt-data + password（共享密钥），Google 要求解析 purchaseToken 并调用 getPurchase 接口验证实时状态——这个逻辑绝不能放在 H5 里做，必须由服务端完成，否则极易被篡改。
