先问个问题你现在的App内购校验是怎么判断“这位用户真的付过钱”的如果答案是“客户端拿到票据自己解析一下、核对一下商品ID就解锁”那你的应用大概率已经被白嫖很久了。我在跟一些独立开发者和中小团队聊内购安全时最常说的一句话就是IAP收据伪造问题的核心不是攻击者能造出一个假票据而是你的服务端把“本应你来验证真假”的工作交给了客户端自己完成。这篇文章会围绕一个非常具体的方案展开生成共享密钥去App Store服务器验证收据然后严格核对凭证里那些无法伪造的字段。我会把这套流程从头到尾拆开讲包括共享密钥怎么生成、经典验证接口和新版App Store Server API怎么选、收据里哪些字段必须比对、以及实战里的各类坑。适合正在做iOS内购、被刷单/盗版/订阅退款问题困扰的开发者参考。1. 为什么明明做了内购还要被白嫖IAP收据伪造的常见攻击方式1.1 本地验证的致命误区客户端判断购买状态是最常见漏洞先统一一下认知IAP收据伪造绝大多数情况下根本不需要“伪造”收据本身。很多早期App的做法是客户端在支付成功后用系统回调里的SKPaymentTransaction.transactionIdentifier或本地解析appStoreReceiptURL里的字段判断“用户买过没有”然后直接解锁功能。这套逻辑的问题很明显SKPaymentTransaction是客户端内存里的对象越狱环境一旦hook了相关方法恶意用户想让它长什么样它就长什么样。本地解析收据也一样开发者通常在客户端用OpenSSL解析PKCS#7容器读取里面的字段但本地读取到的字段是完全可以篡改的因为你无法验证签名恶意用户改完了重新编码代码里读出来的照样是改后的内容。所以只要你把“判断购买结果”的可信逻辑放在客户端要攻破就只是时间问题。攻击者不需要伪造收据他只需要绕过你的判断逻辑。1.2 我见过的四种典型伪造与重放路径我整理一下实际环境中出现比较多的攻击方式方便你对号入座跨应用借据攻击者从另一个付费App或者自己的测试包里导出一张合法收据替换你现在App的收据。很多App只校验“收据能不能被苹果验证通过”却没有校验bundle_id和app_item_id结果别人家的收据也能解锁你的内容。沙箱收据冒充生产开发者把沙箱环境测试时产生的收据当正式收据用攻击者拿到沙箱票据在生产环境兑换一旦服务端没有区分environment字段就等于免费开通。收据重放A账号购买了一次攻击者把这个收据在B账号上重复提交。服务端如果只验证“收据有效”不记录original_transaction_id对应的归属账号就会出现一单多号无限白嫖。直接改客户端状态缓存这是最常见的“低技术”攻击。开发者把解锁状态写到UserDefaults或本地数据库攻击者改一下plist就解锁了跟收据本身真假没有半点关系。1.3 服务端验证的本质把“信任判断”交给App Store正确的思路其实很朴素你不需要自己判断收据真假你需要做的是把收据原封不动发给App Store服务器让苹果帮你验证然后只信任苹果返回的JSON对象。苹果服务器验证收据时会做以下几件事检查收据是否由App Store正确签名、检查共享密钥是否匹配、检查收据结构是否合法。返回的JSON里有status字段0表示有效其他数字表示各种错误。只有这一步通过了你才进入下一步——核对返回JSON里的业务字段确保这张收据确实属于你的App、确实对应你这个用户、确实是当前交易环境。这里有一个很关键的认知点客户端本地方析出来的收据字段是可伪造的App Store服务器返回的字段才是不可伪造的。所以标题里说的“核对凭证内不能伪造的字段”指的是核对苹果验证后返回的字段而不是在客户端解析收据去核验。理清这一点后面的内容就顺了。2. 先搞定共享密钥App Store Connect控制台里的关键操作2.1 共享密钥到底约束了什么共享密钥是苹果验证收据时用来确认“请求方身份”的一个字符串凭证。你调用verifyReceipt接口时如果请求体里不带这个密钥苹果只返回基础的收据状态带上密钥后苹果才会把自动续订订阅相关的完整信息返回给你并且用于确认这个请求确实是开发者本人发出的而不是第三方拿着一张用户收据到处查询。这个设计本质上解决的是“收据隐私”问题——任何App只要拿到一张收据都能往苹果验证服务器丢一遍。没有共享密钥的限制第三方完全可以收集大量用户收据去批量验证拼凑用户购买行为。加了密钥之后虽然理论上还是可以不带密钥验证状态但拿不到订阅明细和续订状态攻击价值大大降低。2.2 App专用共享密钥与主共享密钥怎么选在App Store Connect里共享密钥分两种类型生成位置适用范围使用场景App专用共享密钥某个App的“App内购买项目”页面仅限某个App大部分应用首选要把某个App的订阅逻辑隔离得最干净主共享密钥用户与访问 → 集成开发者账号下所有App账号下多个App统一管理或做跨App订阅互通时用我个人的建议是能用App专用就优先App专用。原因很简单一旦某个App的密钥泄露影响的只是那一个App如果用主共享密钥轮换时所有App都要跟着改。而且App专用密钥在不同App之间天然隔离排查问题也方便。2.3 一步步生成共享密钥App Store Connect的界面改版比较频繁位置可能漂移但关键词不会变。你直接在控制台里搜“App内购买项目密钥”或“App-Specific Shared Secret”就能找到。大致路径和操作如下进入[App Store Connect]选择“我的App”打开你的应用。找到“App内购买项目”或新版里的“商业化”相关菜单。在“App内购买项目”页面底部/侧边找到“App内购买项目密钥”区块。点击“生成”按钮苹果会产出一串由字母数字组成的密钥形如a1b2c3d4e5f6...。点击“复制”存入你的密钥管理工具。这里要强调的是这个密钥只在生成时完整展示一次关掉页面后就只能“重新生成”不能再次完整查看。所以复制后第一时间存到密码管理器或服务端环境变量里不要随手贴到聊天窗口或Git提交记录里。我曾经见过有人把共享密钥直接写死在App源码里提交到公开仓库这等于把订阅数据的钥匙交给了全网。2.4 密钥泄露与轮换的常见坑共享密钥泄露后补救手段只有一个重置。生成一个新的旧的就失效。但重置之前你要考虑清楚旧密钥是否还被老版本客户端或定时任务使用否则刚轮换完一批线上订阅查询请求会全部报错。稳妥的操作顺序是先在服务端配置里启用新密钥保留旧密钥一段时间确认旧调用方全部切换过去后再彻底停用旧密钥。如果是App专用密钥这个操作还简单一点如果是主共享密钥一定要提前通知运营和客服团队避免问题爆发时排查方向跑偏。另外一个隐蔽问题是有些团队把密钥放在配置中心的明文里没有做权限管控。建议至少放在环境变量里配合密钥管理服务比如云厂商的Secrets Manager并开启访问审计。3. 验证方案选型经典verifyReceipt与App Store Server API3.1 verifyReceipt为什么还可以用但不再推荐聊到验证接口老开发者都很熟悉这个调用POST https://buy.itunes.apple.com/verifyReceipt生产环境用buy.itunes.apple.com沙箱测试用sandbox.itunes.apple.com。请求体是JSON核心字段就三个receipt-data客户端传来的Base64收据、password共享密钥、exclude-old-transactions是否只返回最新交易。这个接口简单直接也是绝大多数存量IAP实现的选择。但苹果近年主推的是App Store Server APIverifyReceipt接口虽然在很多项目里仍然稳定运行但官方文档已经明确标注为旧接口新项目里我强烈建议直接上App Store Server API。原因有三点verifyReceipt只能“被动验证”拿到的是快照数据App Store Server API能主动查询某个交易、某个订阅的实时状态。verifyReceipt需要你把收据Base64整个传过去请求体较大App Store Server API走JWT认证配合客户端拿到的交易标识信息密度更高。苹果的订阅通知V2、退款撤销通知等新能力全部围绕App Store Server API和服务器到服务器通知展开依赖旧接口将来会遇到功能天花板。不管选哪条路共享密钥在自动续订订阅场景下都绕不开只是角色不同verifyReceipt把共享密钥放在password字段里App Store Server API则用密钥参与生成调用凭证同时在通知V2的解密环节使用。3.2 App Store Server API的认证方式与JWS交易信息App Store Server API的认证方式和传统接口不一样它要求你生成一个JWT每次请求带上ississuer ID在App Store Connect的“用户与访问”里查看bid你的App的bundle IDaud固定为appstoreconnect-v1exp过期时间一般取5分钟之内iat签发时间sub和bid相同签名用的私钥是.p8格式的密钥文件也是从App Store Connect生成。注意这个东西和共享密钥不是一回事共享密钥是验证收据时用的字符串.p8私钥是调用API时签名JWT用的。你本地要同时保管好这两个东西很多新手会弄混。App Store Server API获取交易信息时客户端拿到的是transactionIdentifier服务端调用/in-app/v1/transactions/{transactionId}接口查询。返回体里有个signedTransactionInfo字段是一串JWSJSON Web Signature格式的字符串。JWS的header里带着x5c证书链payload经过Base64Url编码后包含交易明细。JWS格式长这样用点号分成三段eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUl... .eyJ0cmFuc2FjdGlvbklkIjoi... .MEYCIQ...第一段是头部第二段是载荷第三段是签名。拿到第二段后Base64Url解码就能看到交易字段比如bundleId、productId、transactionId、originalTransactionId、purchaseDate、expiresDate等。3.3 客户端收据获取从transactionReceipt到transactionIdentifier在iOS 12之前客户端通过SKPaymentTransaction.transactionReceipt拿收据之后苹果把这个属性废弃了统一改成从Bundle.main.appStoreReceiptURL读取收据文件。如果是自动续订订阅或非消耗型项目收据文件里会累积所有交易记录服务端验证时才解析出完整明细。到了App Store Server API的时代客户端不再需要传输整个收据文件只要在交易成功后把transactionIdentifier交易唯一标识交给服务端即可。服务端拿这个标识去查交易详情。这一步能轻量化不少也减少收据样本被中间链路截获的风险。收据的刷新逻辑也要注意如果appStoreReceiptURL的路径上不存在文件说明用户还没发生任何购买这时候用SKReceiptRefreshRequest请求系统刷新收据。刷新收据需要用户在App Store重新输入密码不能静默完成所以通常只在主动询问用户是否恢复购买时使用。3.4 完整调用流程客户端到服务端再到App Store不管是旧接口还是新API核心链路是一致的用户在App内完成支付系统回调paymentQueue(_:updatedTransaction:)状态为.purchased。客户端拿收据文件或transactionIdentifier连同自己生成的会话随机数nonce一起发给你的服务端。服务端先校验这个用户是否已登录、请求是否带了合法会话然后把票据转发给App Store服务器。App Store服务器返回验证结果JSON。服务端核对关键字段确认无误后把订单状态写入数据库再返回解锁指令给客户端。这里最关键的一步是第5步的字段核对。很多人验证完status 0就完事了等于只做了半边活儿。下面一节专门讲字段怎么核对。4. 逐字段核对凭证里那些“伪造不了”的硬字段4.1 收据JSON的字段全景与层级用旧版verifyReceipt验证时苹果返回的顶层结构大概长这样{ status: 0, environment: Production, receipt: { bundle_id: com.example.app, app_item_id: 123456789, in_app: [ { transaction_id: 1000000..., original_transaction_id: 1000000..., product_id: com.example.app.vip, purchase_date_ms: 1700000000000, expires_date_ms: 1700003600000 } ], request_date: ..., original_purchase_date: ... }, latest_receipt_info: [], latest_receipt: base64..., pending_renewal_info: [] }新版App Store Server API返回的signedTransactionInfo解出来之后字段是扁平风格的比如bundleId、productId、transactionId、originalTransactionId、environment、type、purchaseDate、expiresDate但含义和上面一一对应。先讲最重要的原则这些字段本身在苹果返回给你的时候就已经经过签名保护了。攻击者无法篡改。你需要做的是把这些字段和你的业务上下文做交叉核对找出“字段有效但业务上对不上”的异常情况。4.2 第一梯队bundle_id、app_item_id、environment这三个字段是所有验证里最基础也最不能省的。bundle_id收据所属App的应用标识。必须和你的App完全一致。这一步防的是跨应用借据。如果你的App是com.example.app收据里却是com.example.other直接拒绝。app_item_idApp在App Store里的数字ID也就是苹果后台显示的“Apple ID”。这个字段比bundle_id更隐蔽因为攻击者完全可以编一个和你一样的前缀但数字ID很难猜。核对方式就是和App Store Connect里显示的App ID做比对不一致直接拒绝。environment收据的环境来源。取值只有Sandbox和Production。生产环境App、TestFlight版本和沙箱测试的收据环境都不一样必须根据当前请求场景严格判断。典型的错误是生产环境收到Sandbox收据直接放行或者用沙箱票据冒充正式购买。这三个字段核对完已经挡住80%的粗放攻击了。4.3 第二梯队in_app交易明细与original_transaction_idin_app数组里是每笔交易的明细你可能要面对两种场景非消耗型项目买断功能、永久会员看in_app里对应的product_id是否匹配并且检查是否存在至少一笔状态正常的交易。自动续订订阅看in_app里的expires_date是否在“当前时间”之后订阅是否还有效。重点核对这几个字段product_id必须匹配你后台配置的商品ID不能出现“用A商品买到的凭证去解锁B商品功能”的情况。虽然正常支付流程不会产生这种凭证但攻击者可能拿着其他App的收据或者历史测试收据来试错。transaction_idApple生成的唯一交易号。服务端必须记录这个值同一笔交易不能重复解锁。这里要注意区分transaction_id是单次交易的IDoriginal_transaction_id是贯穿整个订阅/买断周期的原始ID。original_transaction_id这是防重放的关键。对于非消耗型项目用original_transaction_id关联用户账号同一个original_transaction_id只能绑定一个账号除非是家庭共享的场景。攻击者拿同一张收据去多个账号重复兑换如果服务端只比对transaction_id而不记录original_transaction_id的归属就会被刷穿。我在之前的核查中见过这个案例某App只把transaction_id存到用户订单表攻击者生成多笔相同订阅的收据重放因为每次transaction_id都一样服务端检测到了重复但开发者在逻辑里写的是“发现重复直接返回已解锁”没有去校验“这个original_transaction_id是不是已经属于另一个账号”等于开放了一个多账号白嫖入口。4.4 订阅专属latest_receipt_info与pending_renewal_info自动续订订阅比买断复杂的地方在于用户的状态是动态的可能正常续费、可能取消、可能过期、可能退款。所以光看in_app里的expires_date还远远不够。latest_receipt_info里包含该订阅最新一次的续订状态是所有交易记录里expires_date最大的那条。你要比对的字段包括expires_date当前订阅的到期时间如果已经早于当前时间说明订阅已过期。is_trial_period是否是试用期。很多App把试用期也当付费处理导致被无限创建新账号刷试用。is_in_intro_offer_period是否是 introductory offer 期间。cancellation_date是否存在。如果存在且非空说明这笔订单已经被App Store或用户取消不能再发放权益。pending_renewal_info数组代表处于续订待处理状态的订阅比如用户因为支付方式失效没有续费成功但还在宽限期内。这里需要关注auto_renew_status和expiration_intent字段。严格来说一个订阅只要latest_receipt_info里expires_date未到期就可以认为有效但如果苹果已经标记expiration_intent说明用户明确不想续了你要根据产品策略决定是继续给权益还是做挽留。4.5 防止“借据”用request_data把收据绑定到具体会话前面说的都是收据本身的内容还有一个容易被忽略的隐患你的服务端可能收到一张合法但根本不是“当前用户”的收据。举个例子A用户购买后把收据内容导出发给同伙BB在自己的客户端上把这个收据提交给服务端。服务端验证收据发现完全合法bundle_id对得上、transaction_id也是未用过的就给B也解锁了。这就是“借据攻击”。旧版verifyReceipt接口提供了request_data字段来解决这个问题。你在发给苹果的请求里带上request_data参数内容可以是你服务端生成的、和当前用户会话绑定的随机字符串nonce。苹果在返回的JSON里会把request_data原样带回来服务端比对一下是否和当前会话匹配不匹配就拒绝。这样攻击者即使拿到合法收据也拿不到和收据配套的request_data因为那是绑定在他自己账号会话里的。新版App Store Server API的JWS交易信息里没有直接的request_data但你可以通过传transactionIdentifier给服务端服务端查询时核对交易归属方和当前登录用户的关系来完成同样的绑定目标。核心思路不变收据/交易标识必须和具体业务订单绑定不能只认“苹果说有效”就发权益。5. 服务端校验落地从验收到解锁的完整实现5.1 服务端收据验证的最小实现下面我用一段带注释的风格化代码展示服务端校验逻辑语言用接近JavaScript的伪代码重点不在语法而在校验顺序async function verifyReceipt(receiptBase64, sessionNonce, userId) { const payload { receipt-data: receiptBase64, password: process.env.APP_STORE_SHARED_SECRET, exclude-old-transactions: true, request_data: sessionNonce }; const res await fetch(https://buy.itunes.apple.com/verifyReceipt, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload) }); const json await res.json(); // 第一步苹果的基本校验结果 if (json.status ! 0) { // 21007表示沙箱收据发到了生产接口这里根据业务决定是否重试沙箱 throw new Error(APPLE_STATUS_ json.status); } // 第二步核对凭证内不能伪造的硬字段 const receipt json.receipt; // bundle_id 必须精确匹配 if (receipt.bundle_id ! com.example.app) { throw new Error(BUNDLE_ID_MISMATCH); } // app_item_id 也必须匹配 if (Number(receipt.app_item_id) ! 123456789) { throw new Error(APP_ITEM_ID_MISMATCH); } // environment 必须匹配当前环境测试环境可单独放行 const allowedEnv isDevMode(userId) ? [Sandbox, Production] : [Production]; if (!allowedEnv.includes(json.environment)) { throw new Error(ENV_MISMATCH); } // request_data 回包一致性校验防止借据 if (receipt.request_data ! sessionNonce) { throw new Error(SESSION_NONCE_MISMATCH); } // 第三步遍历交易明细锁定商品 const targetProduct com.example.app.vip; const matchedTx (receipt.in_app || []).find( item item.product_id targetProduct ); if (!matchedTx) { throw new Error(PRODUCT_NOT_FOUND); } // 第四步检查是否已经被其他账号绑定防重放 const existingOwner await db.query( SELECT user_id FROM order WHERE original_transaction_id ?, [matchedTx.original_transaction_id] ); if (existingOwner existingOwner.user_id ! userId) { throw new Error(TX_ALREADY_BOUND); } // 第五步写入订单发放权益 await db.insert(order, { user_id: userId, transaction_id: matchedTx.transaction_id, original_transaction_id: matchedTx.original_transaction_id, product_id: matchedTx.product_id, purchase_date: matchedTx.purchase_date_ms, environment: json.environment }); return { ok: true, expiredAt: null }; }这段代码是典型的最小完整校验链。你可以看到真正的校验不等于“苹果说有效”而是把苹果返回的这些不能伪造的字段一关一关跟你的业务状态对上。5.2 非消耗型与自动续订订阅的差异化处理非消耗型商品处理相对简单核心是防止重放和重复绑定。但自动续订订阅要做的事情更多因为你要持续判断“用户当前到底还有没有权限”。自动续订订阅的服务端逻辑建议单独跑一个定时任务或监听通知去同步状态。两个途径轮询latest_receipt_info每次用户请求权益时实时验证最新收据优点是最新缺点是每次都要等网络请求。监听App Store Server Notifications V2苹果在订阅状态变化续订、过期、退款、用户取消时主动推送通知给你的服务器。这才是服务端真正正确的实时同步方式。通知V2的payload是加密的需要你用共享密钥做AES-GCM解密解出来是一个JSON包含signedTransactionInfo和signedRenewalInfo两个JWS字段再验签后读取。这个机制和共享密钥紧密相关所以前面强调密钥要安全保管——它不只是验证收据时要传的参数也是订阅通知的解密钥匙。5.3 退款撤销回调App Store Server Notifications V2还有一个很多团队会忽略的地方用户购买后可能退款。如果服务端只处理“购买成功”而不管“退款”攻击者完全可以买了再退权益却还在。退款场景下苹果会推送类型为REFUND、REVOKE、REFUND_REVERSED等通知。收到通知后要做两件事找到对应的original_transaction_id关联的订单。把订单状态标记为退款/撤销并在服务端取消用户权益。这里有一个现实问题如果是消耗型商品用户退款时东西已经消耗掉了服务端很难强制追回。所以消耗型商品的金额较大时建议考虑服务端延迟发货或风控策略。这不是IAP本身能解决的但和收据验证的健全度直接相关。5.4 服务端校验失败的兜底策略与用户申诉流程苹果服务器的验证偶尔也会因为网络抖动、请求频率过高、证书问题返回失败。这时候如果服务端直接拒绝用户就可能被误伤。我的建议是分几种情况处理网络类错误超时、连接失败不要立即拒绝可以设置静默重试2到3次间隔递增。状态码明确错误比如21003收据无法认证说明收据真的有问题直接拒绝并提示用户检查购买状态。21007/21008环境错位按规则做一次补偿比如沙箱收据打到生产接口时自动改用沙箱URL重试一次这是很多跨环境测试用例的固定操作。用户申诉场景要留好日志。每笔验证请求都记录客户端版本、环境、收据前100位、返回状态码、校验结果。一旦用户反馈“我明明买了却unlock不了”开发者和客服能有据可查。没有日志的服务端验证排查起来会非常痛苦。6. 常见问题排查与避坑实录6.1 错误码对照速查表错误码含义处理建议21000App Store无法读取你提交的JSON对象检查请求体是否合法JSONreceipt-data是否Base64字符串21002receipt-data属性数据格式错误或缺失检查客户端传入的收据是否是完整Base64编码不要做URL编码21003收据无法被认证收据可能被篡改或损坏拒绝解锁21004请求的共享密钥与文件中的密钥不匹配检查服务端配置的password是否和App Store Connect里一致21005收据服务器当前不可用稍后重试不要直接当失败处理21006收据有效但订阅已过期按业务策略处理过期状态21007沙箱收据被发送到生产环境用沙箱URL重试一次21008生产环境收据被发送到沙箱环境直接用生产环境URL重新验证21009内购项目当前不可用检查该内购项状态是否被删除或暂停21010内购项目已从App Store删除提示用户重新购买或联系客服这个表建议直接贴到你团队的Wiki里。日常遇到最多的就是21007和21008这两条都和测试环境管理不规范有关我后面还会展开。6.2 身边真实案例复盘一个教育类App被刷量后的整改之前帮一个朋友做过一次内购安全整改产品形态是教育类App会员买断加订阅混合。当时的实现非常典型客户端支付成功后本地解锁服务端完全不知道用户购买了什么。发现问题是因为数据后台的“会员开通次数”和“支付成功流水”对不上差距明显。排查后定位了几个漏洞客户端通过transaction.transactionIdentifier本地比对后直接改会员状态攻击者用hook工具伪造updatedTransaction回调一分钟内就能让任意账号变会员。服务端没有校验接口攻击者甚至可以直接调用客户端里的解锁方法传参解锁。部分用户改用别的App收据来“借据”验证因为当时服务端没有真正接入苹果验证只是客户端上报了一个“验证成功”的布尔值。整改方案就是这篇文章的完整版App Store Connect里生成App专用共享密钥服务端接入verifyReceipt补上bundle_id、app_item_id、environment、request_data比对所有解锁动作都通过服务端接口完成。整改上线后刷量数据直接归零。整个过程没有用到任何高深的东西就是把该做的字段核对做全了。6.3 另外几个很容易踩中的隐蔽坑讲几个我实际踩过、也看别人踩过的小坑共享密钥写死在客户端。不管你是为了调测方便还是懒密钥一旦打到包里就等于公开。破解者从ipa里提取字符串的成本几乎为零。本地也存一份验证结果。即使服务端验证通过了也不要在客户端sandboxKeychain或UserDefaults里存“已解锁”标记。真心想绕过的人只要清掉这个标记或者反编译改判断逻辑就行了正确的做法是每次启动从服务端拉取权益状态。沙箱和生产共用一套服务端配置。开发阶段需要测试内购建议服务端显式支持“沙箱模式”通过请求头或环境变量区分而不是拿生产配置直接去验证沙箱收据否则就会整天遇到21007。自动续订只验一次。有些团队在用户首次购买时验证一次之后就信任本地到期时间。可本地时间是可以改的更稳妥的是在每次用户打开App或访问付费内容时动态请求服务端判断“当前订阅是否到期”。忽略家庭共享。家庭共享购买的订阅in_app里会出现多笔original_transaction_id相同的交易如果不做适配可能导致同一家庭内多个成员都绑定失败。家庭共享收据的in_app条目中会有is_upgraded、promotional_offer_id等字段判断逻辑要提前设计好。关于JWS验签再补一句新版App Store Server API的signedTransactionInfo虽然你解码后能看到字段但还是建议做一次完整验签确认签名链可追溯。验签时用的根证书是苹果公开的Apple Root CA - G3可以通过苹果的PKI页面下载。不要跳过验证直接信任载荷内容。苹果给的数据在传输链路上是安全的但你的服务端代码如果只是简单Base64解码等于放弃了对数据来源的确认。一个小小的收尾建议在我自己处理IAP安全的过程中最大的体会是收据验证不是一次性工作而是一套持续运行的风控机制。共享密钥生成好、字段校验逻辑补全只是起点后续还要接通知、管退款、盯日志。哪怕没遇到攻击者订阅用户数量上来之后过期状态判断不准确、沙箱生产环境混淆这类问题也一定会暴露出来。最后分享一个我常用的自查清单每次发布内购相关版本前问自己三件事——共享密钥是不是只存在服务端服务端有没有严格比对bundle_id和app_item_id同一张收据能不能被另一个账号重复兑换三个问题都能答上来IAP这块的基础安全就算落地了。