uni.requestPayment 对苹果 IAP 完全无效，因其未封装 StoreKit；必须用原生插件（如 uni-app-iap）调用 SKProductsRequest 等接口，且需开发证书、显式 Bundle ID、沙箱账号等完整配置。
uni-app 无法直接用 uni.requestPayment 调起 iOS 内购，必须走原生桥接；appleiap 通道为空、requestProduct 返回空数组、支付面板不弹出——90% 是基座包或描述文件配置错误，不是代码问题。
为什么 uni.requestPayment 对 IAP 完全无效
苹果 IAP 是 StoreKit 原生框架，uni-app 的 uni.requestPayment 只封装了微信、支付宝等第三方 SDK，压根没接入 StoreKit。调用它只会静默失败或报错 provider not found。
- 必须使用支持 StoreKit 的原生插件，比如社区维护的
uni-app-iap（注意：不是 npm 包，是 HBuilderX 插件市场里的原生插件） - 插件内部会调用
SKProductsRequest和SKPaymentQueue，这些无法被 JS 直接触发 - 所有商品查询、购买、恢复购买、交易验证回调，都依赖插件透出的 JS 接口，例如
iap.requestProduct([productId])、iap.buy(productId) - 服务端验签必须用苹果返回的
result.transactionReceipt（base64 字符串），不是transactionId
自定义基座包必须用「开发证书」，否则 appleiap 通道为 null
云打包或发布证书（Distribution）生成的 ipa，哪怕装在真机上，uni.getProvider 也拿不到 appleiap；只有开发证书（Development）+ 正确 Provisioning Profile 才能激活沙盒环境。
- HBuilderX → 运行 → 运行到手机或模拟器 → 点击「制作自定义基座」→ 勾选「开发证书」，不能勾「发布证书」
- Provisioning Profile 必须绑定已启用
In-App Purchase的 App ID（不能是 Wildcard ID，必须是显式 Bundle ID，如com.example.myapp） - 设备 UDID 必须提前添加进开发者账号的「Devices」列表，否则基座安装失败或 IAP 不可用
- 模拟器完全不支持 IAP，测试必须用真机；且首次运行需手动在「设置 → Apple ID → 媒体与购买项目」里关闭「密码要求」，否则支付面板卡死
requestProduct 返回空数组的 4 个硬性条件
即使 appleiap 通道存在，iap.requestProduct([productId]) 仍可能返回空或静默失败——这不是网络问题，而是苹果沙盒识别失败。
- 内购商品状态必须是
Ready to Submit或Approved（Draft 状态不会出现在沙盒产品列表中） - 商品 ID（
productId）必须和 App Store Connect 中创建的完全一致，大小写敏感，且不能含空格或特殊字符 - 测试账号必须是沙箱账号（
@test.com后缀），且已在「设置 → Apple ID → 媒体与购买项目 → 沙箱账户」中登出再重新登录 - App ID、Provisioning Profile、Xcode 工程（如果本地调试）三者使用的 Bundle ID 必须完全一致
服务端验签地址和参数必须严格区分沙盒/正式环境
苹果对沙盒和生产环境使用不同验签接口，且响应结构略有差异；用错地址会导致验签永远失败，返回 21007 或 21008 错误。
- 沙盒验签地址：
https://sandbox.itunes.apple.com/verifyReceipt - 正式环境地址：
https://buy.itunes.apple.com/verifyReceipt - 请求体必须是 JSON：
{"receipt-data": "base64字符串", "password": "共享密钥（如有）"} - 共享密钥（
password）只在开启了「订阅密钥」的 App ID 下才需要填，普通消耗型商品可不传 - 上线前务必关掉客户端的沙盒开关（部分插件提供
useSandbox: true/false配置），否则会持续发往沙盒地址
最易被忽略的一点：苹果的 IAP 流程本质是「前端只负责唤起和监听，所有业务逻辑（库存扣减、权益发放、防重放）必须由服务端完成」；客户端拿到 transactionReceipt 后立刻上传，不要缓存、不要重试、不要自行解析 receipt 内容——苹果明确不保证其格式稳定性。
