苹果内购回调PHP处理核心是必须用官方接口二次验签并自动适配沙盒/正式环境；需清洗receipt-data换行符、先正式地址验签失败再按status码切换、从in_app数组取transaction_id等字段、v2订阅通知需JWT验签且与v1不兼容。
苹果内购回调 PHP 接收和处理的核心是：别直接信客户端传的 receipt-data，必须用 Apple 官方接口二次验签，且要自动适配沙盒/正式环境 —— 否则 90% 的失败都卡在这一步。
怎么接收 iOS 传来的 receipt-data？注意换行和 base64 编码陷阱
iOS 端调用 SKPaymentTransaction.transactionReceipt 后会返回原始二进制数据，再经 base64EncodedString(options: .endLineWithLineFeed) 编码 —— 这意味着字符串里可能含 \n 和 \r，但 PHP 的 $_POST 或 $this->request->post() 默认不会自动 trim 换行符，会导致验签失败（状态码 21002）。
- 务必对
receipt-data做str_replace(["\n", "\r"], "", $receipt_data)清洗 - 绝对不要对
+、/、=做 URL 解码或替换（iOS base64 不用 URL-safe 变种） - 长度校验不能只看
strlen，要先清洗再判断：if (strlen($receipt_data) （真实票据一般 >1000 字符）
如何自动判断沙盒 or 正式环境？别硬编码开关
Apple 要求：沙盒票据只能发给沙盒地址验证，正式票据只能发给正式地址。但 iOS 客户端不告诉你当前是哪个环境，也不能靠 is_test 参数（它不可靠，且新版 iOS 已弃用）。
- 正确做法：先用正式地址
https://buy.itunes.apple.com/verifyReceipt请求一次 - 如果返回
status === 21007（沙盒票据打正式地址），立刻用沙盒地址重试 - 如果返回
status === 21008（正式票据打沙盒地址），说明客户端配置错，应记录日志并拒绝 - 别用设备 UDID、Bundle ID 或 IP 判断环境 —— 全部无效且违反 Apple 政策
验签成功后怎么提取关键业务字段？重点看 in_app 数组
验签返回的 JSON 中，有效购买信息全在 receipt['in_app'] 数组里（即使单次购买也是数组），不是顶层 receipt 字段。常见误操作是直接读 $data['receipt']['product_id'] —— 会报错或取空。
-
transaction_id是唯一支付 ID，必须存库用于防重（Apple 允许同一票据多次提交，但transaction_id绝对唯一） -
original_transaction_id对订阅首次购买很重要，续订时保持一致 -
purchase_date_ms是毫秒时间戳，PHP 用(int)($item['purchase_date_ms'] / 10转为标准时间
00) - 检查
quantity字段，避免客户端恶意改包传高数量（如买 1 次传 quantity=999）
00)v2 订阅通知（JWS）和传统 receipt 验证完全不是一回事
如果你接入的是 Apple 订阅服务（尤其是自动续期订阅），2025 年起 Apple 强制要求使用 v2 通知（JWS 格式），它不是 JSON，而是三段 base64 字符串（header.payload.signature），需用 JWT 库 + 苹果根证书验签，和老的 verifyReceipt 接口互不兼容。
- v2 通知是 Apple 主动 POST 到你服务器的 Webhook（不是客户端回调），路径如
/api/apple/notify - 必须验证
$header['x5c'][0]是否匹配苹果官方AppleRootCA-G3.pem（不是系统自带证书） - 不能用
json_decode直接解 payload —— 必须用JWT::decode($jws, $public_key, ['RS256'])，否则验签失败 - 老项目还在用 v1 receipt 验证的，只要没上订阅功能，可暂不升级；但凡有订阅，v1 就无法处理退款、续订、过期等事件
最常被忽略的一点：Apple 的 verifyReceipt 接口响应中，status === 0 只代表票据格式合法，不代表「这笔钱已到账」—— 你还得比对 bundle_id、product_id、transaction_id 是否与你订单一致，否则黑产可复用他人票据完成虚假支付。
