闲鱼上搜 "ChatGPT Plus"，5 块到 150 块的报价一字排开。
你有没有想过一个很基本的问题：凭什么？
OpenAI 官方定价 20 美元一个月，折人民币 145 左右。这些卖家哪来的成本优势？
答案藏在一个你意想不到的地方——不在 OpenAI，在苹果。
准确地说，在苹果搞了 14 年的"App 内购收据验证"机制里。这套机制从 2011 年 iOS 5 时代就有了，到今天还在坑人。不是坑用户，是坑开发者。而开发者被坑的结果，就是你在闲鱼上看到的那些离谱价格。
今天就把这事儿从根上讲明白。
· · ·
一张收据，到底证明了什么
你在 iPhone 上买一个 App 内购——比如给 ChatGPT 开 Plus，走的流程大概是：
你点"购买" → App Store 扣款 → 苹果在你手机本地生成一份数字收据 → App 拿到收据 → App 把收据发给自家服务器 → 服务器验证收据真伪 → 验过了，给你开通服务。
听起来没什么，对吧？
第一个反直觉的事实来了：这张收据上，没有你的 Apple ID。
苹果出于隐私保护的考虑，收据里只包含几样东西：App 的 Bundle ID（就是"这个 App 是谁家的"）、商品 ID（"买的是什么东西"）、交易流水号、购买时间。
买家是谁？不告诉你。
苹果 Developer Forums 上有一位开发者说得很直白：苹果的验证服务器根本不检查设备标识符（identifierForVendor），所以你无法确认收据是不是来自这台设备上的这个用户。他说他试图向苹果反馈这个安全问题，但苹果从未回应过。
这意味着什么？如果开发者的服务器只做了"验证收据是不是真的"这一步，但没有自己额外建一套"收据-账号"的绑定逻辑——任何人拿着一张合法收据，都能给任意账号开通服务。
这就像一张电影票上只写了"《复仇者联盟》19:30 3号厅"，但没写持票人姓名。验票员只看票是不是真的，不看人是不是对的。
· · ·
2012 年，一个俄罗斯人把这件事捅穿了
2012 年 7 月，一个叫 Alexey Borodin 的俄罗斯人做了一件事，直接把整个 iOS 内购体系的底裤扒了下来。
他的做法并不复杂：搭一个假的"苹果验证服务器"，用 DNS 劫持让 iPhone 上的 App 把验证请求发到他那里去，再回复一句"这张收据是真的"。
那时候大量 App 的验收逻辑是直接在手机端和苹果服务器通信的——苹果自己的文档就是这么教的。Borodin 只需要在中间截一刀，整个验证就形同虚设。
MacRumors 当时的报道提到一个细节：Borodin 的服务只需要一张被"捐赠"的真实收据，就可以拿它给无数人的购买请求做认证。 很多收据还是 Borodin 自己花了几百美元买内购产品生成的。
更要命的是，Borodin 后来告诉 Macworld，他发现用户的 Apple ID 和密码在整个通信过程中是明文传输的。他说："我能看到 Apple ID 和密码，只是看不到信用卡信息。"开发者 Marco Tabini 评论说："苹果以为自己在跟自己的服务器通信，所以没加密。这完全是苹果的锅。"
这个事件闹大之后，苹果做了什么？写了一份紧急文档《In-App Purchase Receipt Validation for iOS 5.1 and Earlier》，核心就一句话：别在手机端直接连苹果的服务器做验证，改成走你自己的服务器。
但这只解决了"假服务器"问题。另一个更深层的问题——"一张收据能被反复用"——苹果并没有在系统层面彻底解决。它把这个包袱甩给了开发者：你自己记住每张收据的流水号，用过一次就作废，别重复发货。
听起来不难？继续往下看。
· · ·
苹果给你埋的雷：21007
每个写过 iOS 内购的开发者都被一个数字折磨过：21007。
苹果后台有两套环境：生产环境（用户花真金白银买的）和沙箱环境（开发者测试用的，不扣钱）。两套环境各有一个验证服务器地址，把生产收据发到沙箱地址会报错，反过来也一样。
但苹果的"最佳实践"是这么写的：
先把收据发到生产服务器验证。如果返回错误码 21007，说明这其实是沙箱收据，你再转发到沙箱服务器重新验证。
为什么要这么搞？因为 App Store 审核员在审你 App 的时候用的是沙箱账号。如果你的代码里只写了"发往生产服务器"，审核员一测就报错，你的 App 就会被拒。
结果就是：每个开发者的验证代码里都必须内置这条"先试生产、失败转沙箱"的回退逻辑。写对了没事，写错了——比如在生产环境里不小心接受了沙箱收据——就等于给自己开了个后门：一张不花钱的测试收据也能换真服务。
这不是假设。苹果 Developer Forums 上有一整个帖子在讨论这个问题，开发者们互相提醒哪些写法会踩坑。2016 年苹果突然换了一次签名证书，所有用老方法做本地验证的 App 瞬间全炸，论坛上哀鸿遍野。
· · ·
2023 年，一个独立开发者被薅了 2500 美元
你以为这些是老黄历了？2023 年 12 月的事。
一个叫 Ronald Mannak 的开发者，做了一款叫 Pico 的 App——本质上是一个 ChatGPT 的第三方客户端。他在 App 里内置了自己的 OpenAI API 密钥，用户通过 iOS 内购订阅后可以使用。
然后他被黑了。
黑客绕过了他的内购验证，直接白嫖他的 API 额度。他在 Medium 上写的原话是：攻击者迅速用光了他每月 2500 美元的 OpenAI API 限额，导致一笔意外账单，还迫使他在圣诞销售旺季把 App 下架。
Mannak 花了五个月时间，和苹果工程师反复沟通，才搞明白怎么在 StoreKit 2 下正确验证内购。他把这段经历写成了一篇长文，标题叫《How to Validate iOS and macOS In-App Purchases Using StoreKit 2 and Server-Side Swift》。
文章里他提到一个让他困惑了很久的事：苹果在 StoreKit 2 里弃用了旧的 verifyReceipt 端点，换了一套全新的 JWS（JSON Web Signature）验证机制。但苹果文档对这个迁移的描述极其晦涩。原文是这么写的：
"To validate receipts on your server, follow the steps in Validating receipts on the device on your server."
Mannak 的反应是："这句话到底是什么意思？"
他后来发现，用 StoreKit 2 做的内购，收据并不会自动更新到 App Store Receipt 文件里。也就是说，你在客户端买了东西，服务器用旧方法去验——合法购买，但验证失败。他的 TestFlight 用户遇到这个问题，App Store 审核也遇到。找了几个月才定位到根因。
一个全职开发者，做的是最主流的产品（ChatGPT 客户端），用的是苹果最新的框架，花了五个月才把内购验证搞对。 这就是这个问题的真实难度。
· · ·
为什么到今天还搞不对
把上面这些串起来看，你会发现一个模式：
苹果不断地在改验证机制——从 StoreKit 到 StoreKit 2，从 verifyReceipt 到 App Store Server API，从被动验证到 Server Notifications V2。每一次迭代都修掉了一些旧漏洞，但同时引入了新的复杂度。
而开发者面临的核心困境始终没变：
第一，收据不绑人。 苹果至今没有在收据里内置"这是哪个用户买的"这层信息。开发者必须自己建绑定逻辑，但苹果的文档对"怎么绑"几乎没有指导。
第二，去重靠自己。 一张收据被用过之后标记为"已使用"——这件事苹果不帮你做，你自己在数据库里记。记漏了，同一张收据就能被反复使用。
第三，测试几乎不可能完整覆盖。 真实的退款回调、真实的跨区购买、真实的家庭共享、真实的订阅到期——这些场景在开发阶段根本复现不了。很多 bug 只有上线之后、被人盯上了才会暴露。
第四，文档分散且自相矛盾。 StoreKit、StoreKit 2、App Store Server API、App Store Server Notifications——四套东西的文档分散在苹果开发者网站的不同角落，写的人都不是同一批，措辞口径不完全一致。一个工程师想搞明白完整流程，至少得看七八篇文档外加好几个 WWDC Session。
第五，激励是错位的。 验票写严了，正常用户换手机、换 Apple ID、家庭共享都会撞墙，客服量暴涨。验票写松了，每个月少收一点订阅费，但用户无感。很多团队宁愿选后者。
结果就是：绝大多数 App 的内购验证都是"差不多能用"的水平，而不是"严格正确"的水平。 这中间的缝隙，就是灰色市场赖以生存的土壤。
· · ·
闲鱼上那些便宜的 Plus，到底怎么来的
回到开头的问题。闲鱼上的低价 Plus 来源并不单一，但有一条路径是最好理解的——区域定价差。
土耳其、阿根廷、印度这些地区，App Store 里的订阅价格比中国大陆便宜得多，有的只有国内定价的一半甚至三分之一。这不是秘密，打开苹果官网的价格表就能看到。
有人会专门注册这些低价区的 Apple ID，用当地的礼品卡充值，然后以低于国内官方定价、但高于低价区成本的价格转卖。赚的是价差。
这是最"干净"的一条路——成本明明白白，利润可算。
但还有其他路径，成本更低，也更灰。上面讲的那些验证机制的缝隙——收据不绑人、去重不严格、环境判断有坑——都有可能被利用。
具体是怎么利用的？我不讲操作细节，因为一旦变成教程，性质就不一样了。你只需要知道一件事：只要一个 App 的收据验证做得不够严格，理论上就存在"一张合法收据给多个账号发货"的可能。
闲鱼上那些二三十块的 Plus，成本到底是来自区域差价还是来自验证缝隙，从外面看是分不清的。但有一件事是确定的：价格越偏离正常水平，风险越高。
风险不只是"号突然不能用了"。
共享账号意味着你的所有聊天记录——你跟 AI 聊的工作内容、个人隐私、甚至你上传的文件——别人登进来全都能看到。这不是理论风险，这是默认行为：ChatGPT 的对话历史在同一个账号下是全部可见的。
· · ·
所以，这到底是谁的锅
这篇文章讲下来，你可能觉得我在黑苹果。
不是。苹果的 IAP 系统在安全性上已经做了非常多工作——StoreKit 2 引入的 JWS 签名机制比旧方案强了一个数量级，App Store Server Notifications V2 让退款和续费状态的同步变得靠谱得多。
但问题的本质是：苹果设计了一套"半成品"——它帮你验证了收据是真的，但"这张收据该发给谁""这张收据用过没有"这些关键判断，全都留给开发者自己做。
有些开发者做对了——Netflix、Spotify 这类大厂有专门的支付安全团队，把每一个边界条件都堵死了。
有些开发者做得差不多——能拦住 80% 的异常情况，剩下 20% 靠运气。
还有些开发者压根没做——收据来了，验一下真假，通过就发货。这种代码在 GitHub 上的 IAP 教程里比比皆是，很多新人就是照着抄的。
14 年了，同一个工程问题，同样的坑，不同的人前赴后继地踩进去。
不是因为他们蠢，是因为这件事真的很难。验一张票容易，验对一张票，需要理解密码学签名、分布式状态一致性、跨环境路由、回调幂等性、退款状态机——随便一个方向挖进去，都是能讲一个学期的课。
工程师这个行当，最贵的从来不是写代码。是在"看起来没什么"的角落里做判断。 一个验票逻辑写对写错，差别可能是每月几万块的灰色损失，或者一个独立开发者圣诞节那天收到的 2500 美元账单。
而你在闲鱼上看到的那个 25 块钱的 Plus——
它的价格标签背后，站着一条 14 年没修完的工程裂缝。