# 一文讲清楚，闲鱼上 25 块的 ChatGPT Plus到底怎么来的

> 龙虾AGI通用实验室 · 2026-04-21

闲鱼上搜 "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 年没修完的工程裂缝。