PHP验证苹果支付凭证异常时，需依次捕获cURL网络错误、校验JSON解析安全性、分层识别苹果status状态码、防御in_app数组结构异常、隔离敏感字段并日志脱敏。
如果您在PHP服务端验证苹果支付凭证时遭遇异常响应或流程中断，则可能是由于网络请求失败、凭证格式错误、沙盒/生产环境错配或苹果接口返回非预期状态码所致。以下是捕获与处理此类异常的具体步骤：
一、捕获cURL底层网络异常
在调用苹果验证接口（https://buy.itunes.apple.com/verifyReceipt 或 https://sandbox.itunes.apple.com/verifyReceipt）时，需主动检查cURL执行过程中的错误状态，而非仅依赖HTTP响应体内容。
1、在curl_exec()之后立即调用curl_error()和curl_errno()获取错误信息。
2、若curl_errno()返回非0值（如CURLE_COULDNT_CONNECT、CURLE_SSL_CACERT、CURLE_OPERATION_TIMEDOUT），说明网络层已失败，不应继续解析$response。
立即学习“PHP免费学习笔记（深入）”；
3、记录完整错误码与错误字符串至日志文件，例如：file_put_contents($log_file, "cURL error {$errno}: {$error}", FILE_APPEND)。
二、校验JSON解析安全性
苹果返回的数据始终为JSON格式，但网络传输中可能因截断、编码错误或代理干扰导致响应体不完整或含非法字符，直接json_decode()将返回null，引发后续空数组访问异常。
1、调用json_decode($response, true)后，立即使用is_array()或json_last_error()判断解析结果有效性。
2、若json_last_error() !== JSON_ERROR_NONE，应记录原始$response（截取前500字符防日志爆炸）并返回统一错误码，如'status' => false, 'message' => 'Apple response JSON parse failed'。
3、禁止对未校验的$data['status']等字段做intval()或isset()以外的直接访问操作。
三、分层识别苹果状态码异常
苹果验证接口返回的status字段是核心判断依据，但21007/21008等环境错配状态需二次验证，而21004等需补传password参数，必须按类型差异化处理。
1、提取$data['status']并强制转换为整型，避免字符串比较陷阱。
2、对status为21007或21008的情况，立即切换验证地址重试（沙盒→生产 或 生产→沙盒），且重试前需清除原curl句柄并重建。
3、当status为21004时，检查是否已传入password参数；若未传，则携带shared secret重发请求，password必须与App Store Connect中配置的完全一致（区分大小写、无空格）。
四、防御in_app数组结构异常
苹果返回的receipt['in_app']是一个无序数组，且可能为空、为单元素或含多个历史购买记录。若代码假定其存在或固定索引（如$in_app[0]），将触发PHP Notice或逻辑错乱。
1、先判断isset($data['receipt']['in_app'])且is_array($data['receipt']['in_app'])，否则视为无效收据。
2、对$in_app执行array_filter()剔除空项，再用array_multisort()按purchase_date_ms或purchase_date降序排列。
3、取排序后首项作为本次交易依据，严禁使用索引0硬取，必须校验purchase_date是否匹配当前订单时间窗口（建议±300秒容差）。
五、隔离敏感字段与日志脱敏
凭证数据receipt-data长度超8000字符，含Base64编码的敏感信息；若全量写入日志，违反PCI DSS及GDPR基本要求，且易被日志系统截断或引发磁盘溢出。
1、记录日志时仅保留receipt-data的SHA-256哈希值（hash('sha256', $receipt_data)），不存储原文。
2、对返回数据中的original_transaction_id、transaction_id、product_id等关键业务字段，在日志中做掩码处理（如保留前4位+星号）。
3、所有日志写入前须通过ini_get('log_errors_max_len')限制单行长度，并启用rotate机制防止日志文件无限增长。
