Signal拟推免手机号注册：一次性付费背后的账号体系设计与反滥用权衡

最近，Signal 的一个新动向在加密通讯用户圈子里讨论度很高：官方计划推出一项“一次性付费”选项，让用户可以在不提供手机号的情况下完成注册。

说实话，第一次看到这个消息时，我的第一反应是：“那联系人发现怎么办？”毕竟 Signal 一直把手机号当作账号体系的锚点，去掉手机号注册绝不是改一个表单字段那么简单。在深入了解之后才发现，这个功能背后的工程权衡，远比表面看到的复杂。

如果你正在做账号体系、用户注册、付费验证或者消息系统，这篇文章正好可以把这条产品决策背后的技术逻辑拆开来讲：Signal 为什么坚持手机号？为什么要推出付费免手机号？去掉手机号之后，服务端到底要改哪些东西？

1. 先说背景：Signal 准备做什么？

Signal 是一款免费、开源、端到端加密的即时通讯应用，以 Signal Protocol 加密协议为核心，在安全圈子、记者、开源社区里认可度很高。很多对隐私敏感的用户把它当成日常通讯工具，因为它能保证消息在传输和存储时都不可被服务端解密密文。

最近 Signal 的规划动向是：团队正在评估“不提供手机号也能完成注册”的方案，而替代手机号的核心验证方式很可能是一次性小额付费。也就是说，用户不再需要绑定手机号接收短信验证码，而是通过支付一笔费用来证明自己是真实用户。这个方案目前还没有正式上线，价格和具体上线时间都未确定，但 Signal 官方在公开讨论中已经多次提到这一方向。

作为开发者，我们真正关心的不是“功能什么时候上线”，而是这背后暴露出的产品思路：Signal 想在隐私保护和反滥用之间寻找新的平衡点。手机号虽然能有效阻止垃圾注册，但它本身是一种隐私负担。付费免手机号的出现，本质上是在“注册成本”和“用户隐私”之间做了一次重新的权衡。

1.1 这里的 Signal 是什么？

先做一个范围澄清。不少读者在搜索引擎里搜“Signal”时，会看到信号处理、Vivado 仿真里的 signal 报错、ChatGPT 启动失败日志里的 signal 字段，这些和本文讨论的不是同一个东西。

本文讨论的是由 Signal Messenger 团队开发维护的加密通讯应用 Signal。它的官网是 signal.org，服务端代码和客户端代码都在 GitHub 上开源。Signal 支持全平台，包括 Android、iOS、Windows、macOS、Linux，用户可以发送一对一消息、群组消息、语音视频通话，并且所有传输内容都是端到端加密的。

Signal 本身不靠卖会员或卖广告盈利，主要依赖用户捐赠和基金会资助运营。正是因为它不做商业化榨取，它才敢在注册方式上优先考虑隐私保护。

1.2 “无需手机号注册”具体指什么？

目前 Signal 的注册流程是强绑定手机号的。用户打开 App 输入手机号，服务端发送短信验证码或语音验证码，用户输入验证码后创建账号。手机号既是账号入口，也是好友发现的依据。

“无需手机号注册”的意思是：在注册流程中提供一个可选项，用户不填手机号，而是通过一次性购买某个虚拟商品或服务，用购买凭证完成注册。这个“一次性付费”在这里并不是为了盈利，而是作为一种身份验证成本——用支付成本替代手机号暴露成本。

需要说明的是，因为官方还没有公布具体的实现方式和定价，下面聊到的内容，更多是基于公开信息和技术常识做的推演。但这不影响我们理解它背后的工程逻辑。

2. 现状：Signal 注册流程背后的技术逻辑

在分析“免手机号”之前，我们需要先理解为什么 Signal 一直在注册环节坚持手机号验证。这不是产品经理拍脑袋定的，而是因为手机号在一个成熟的账号体系里承担了多个不可替代的职责。

2.1 当前注册流程拆解

Signal 当前的注册流程可以简化成以下几步：

1. 用户在客户端输入自己的手机号。
2. 服务端调用短信通道或语音通道，向该号码发送验证码。
3. 用户输入验证码，客户端生成密钥对，并把公钥注册到服务端。
4. 服务端记录手机号与账号标识的绑定关系。
5. 用户后续登录、消息投递都基于这个账号体系运行。

整个流程看起来并不复杂，但手机号在系统里承担了四件事：

• 身份唯一性：一个手机号在 Signal 中只能注册一个账号；
• 真人验证：能收到验证码的人，至少拥有一个真实可用的移动号码；
• 联系人发现：用户上传通讯录哈希后，服务端用哈希匹配好友；
• 账号找回：换新设备或重新登录时，可以通过手机号再次验证身份。

所以手机号并不是注册表单里的一个普通字段，而是 Signal 整个账号体系的底座。

下面用一段简化伪代码来表示当前手机号注册的核心逻辑：

# 示意：当前 Signal 注册流程（简化版） def register_by_phone(phone_number: str): # 1. 校验手机号是否已被注册 if account_exists(phone_number): raise AlreadyRegistered("手机号已注册") # 2. 生成并发送验证码 code = generate_verification_code() send_sms(phone_number, code) # 3. 用户回填验证码后创建账号 # 这里省略验证码校验的细节 account_id = create_signal_account(phone_number) return account_id

注意，这只是一个抽象示例。真实 Signal 服务端还需要处理短信发送频率限制、语音验证码回退、设备令牌、验证码过期时间、IP 信誉等大量细节。

2.2 手机号的三重身份

手机号在 Signal 中不是单一职责，而是同时承担身份标识、真人验证、好友发现三个角色。我整理成下面这个表格：

这里最关键的问题是：支付验证可以承担“真人验证”和“注册成本门槛”，但它无法承担“好友发现”和“账号找回”的职责。所以 Signal 不是简单地把手机号字段删掉，而是需要设计一套更完整的账号体系来承接这些能力。

这也是为什么这个功能跳票了很久——它不只是客户端改动，而是服务端账号体系的一次重构。

3. 功能解读：一次性付费作为“无手机号注册”门槛

3.1 为什么不是免费开放注册？

看到这里，很多人会问：为什么不直接去掉手机号，改成用户名注册？这样不是更简单吗？

答案在于反滥用。

如果完全免费开放注册，并且允许用户不提供手机号，机器人可以在短时间内批量创建大量虚假账号。这些账号会被用于：

• 发送垃圾私信；
• 创建垃圾群组；
• 消耗短信验证通道；
• 污染联系人匹配结果；
• 给其他用户带来骚扰和信任危机。

手机号虽然不完美，但它有一个很好的特性：获取成本高。申请一个新手机号通常需要实名和月租，批量注册成本很高。即使有卡商大量囤卡，整体成本也比“免费注册”高得多。

因此，“一次性付费”从本质上来说，是在替代“手机号验证码”这个成本门槛。Signal 官方讨论这一方向时也强调过：付费的目的不是利润，而是防止滥用。对于这种体量的隐私通讯产品，如果用户不需要付出任何成本就能批量注册，那么整个社区的信任模型会立刻崩塌。

3.2 付费会不会泄露隐私？

一次性付费如果设计不好，反而会比手机号更泄露隐私。

试想，如果 Signal 直接接入 Stripe、支付宝、微信支付，那“免手机号注册”就失去了意义——支付渠道掌握着真实姓名、支付账户、银行卡等信息，隐私级别比手机号还要低。所以真正可行的方案是走应用商店内购通道，或者购买匿名兑换码。

大致流程如下：

1. 用户从 App Store 或者 Google Play 购买“免手机号注册”虚拟商品；
2. 应用商店返回一个购买凭证（purchase token 或 receipt）；
3. 客户端把这个凭证发送给 Signal 服务端；
4. 服务端调用应用商店的验证接口，确认凭证合法；
5. 验证通过后，为该 Signal 账号标记为“无手机号注册”。

在这个模型下，Signal 服务端只知道“有一个有效的购买凭证”，并不知道购买者到底是谁。应用商店知道购买者的身份，但它无法把购买者身份与某个 Signal 账号直接对应起来。这就是支付验证与身份信息隔离的核心理念。

3.3 一次性支付的服务端校验流程

下面给出一段示意代码，展示服务端如何处理购买凭证：

# 示意：购买凭证校验与账号绑定 def handle_purchase_token(account_id: str, purchase_token: str): # 1. 校验购买凭证是否真实有效 is_valid = verify_store_receipt(purchase_token) if not is_valid: raise InvalidPurchaseToken("购买凭证无效") # 2. 检查凭证是否已经被使用过 if receipt_already_used(purchase_token): raise ReceiptAlreadyUsed("该购买凭证已使用") # 3. 将账号标记为无手机号注册 mark_account_as_no_phone(account_id) # 4. 绑定购买凭证与账号，防止重复使用 bind_receipt_to_account(account_id, purchase_token)

核心逻辑包括三点：

• 凭证真实性校验：确保客户端的购买凭证不是伪造的；
• 凭证唯一性校验：一个购买凭证只能绑定一个账号，防止“一票多用”；
• 账号状态更新：账号标记为免手机号模式，后续登录流程不再依赖手机号。

真实项目中，verify_store_receipt通常要对接苹果 App Store Server API 或 Google Play Developer API。这两家商店的凭证格式和校验方式不同，但整体套路是一样的：拿到凭证，请求服务端验证，校验返回值，再把账号状态落库。

4. 技术拆解：去掉手机号注册需要改造哪些系统

如果 Signal 正式上线“免手机号注册”，工程改动会涉及认证、联系人、数据恢复、风控等多个模块。我们逐个来看。

4.1 注册与认证链路改造

无手机号账号的注册流程大致可以设计成：

1. 用户点击“不使用手机号注册”；
2. 客户端引导用户完成一次性购买，拿到购买凭证；
3. 客户端把购买凭证发送给服务端；
4. 服务端校验凭证并创建账号；
5. 为账号生成一个独立的恢复密钥，用于换设备时恢复数据。

和手机号注册相比，唯一被替换掉的是“验证码”这一步。之前由短信验证码完成真人验证，现在由支付凭证完成。但后续的认证链路发生了变化：手机号注册的用户可以随时用手机号重新登录，而无手机号用户则需要依赖别的凭证。

可能的替代验证方案包括：

• 设置独立用户名；
• 绑定密码或恢复码；
• 生成一组助记词；
• 使用恢复密钥（Recovery Key）。

这种设计在去中心化产品、加密钱包中很常见，Signal 如果想长期支持无手机号账号，大概率会参考类似方案来设计密钥找回流程。

4.2 联系人发现机制的替代方案

手机号注册有一个隐形的优势：用户不需要主动告知自己的账号标识。只要通讯录里保存了好友的手机号，而好友也注册了 Signal，App 就会通过通讯录哈希匹配自动显示出联系人。

无手机号账号享受不到这种便利。Signal 已经推出了用户名（Username）功能，用户可以设置一个公开用户名，让别人通过用户名找到自己。这一点正好可以作为无手机号账号的好友发现基础。

未来无手机号账号可以依赖以下几种方式添加好友：

• Signal 用户名搜索；
• 扫描二维码；
• 粘贴邀请链接；
• 从共同群组中添加。

产品体验上，这实际上是从“通讯录自动发现”转向“主动分享身份信息”。用户需要主动把自己的 Signal 用户名或二维码发给朋友，使用门槛确实会比手机号注册高一些，但隐私收益也更高。

4.3 账号找回与数据迁移

手机号注册用户找回账号很简单：重新输入手机号，接收验证码，重置设备，恢复聊天记录。

无手机号用户如果换手机，服务端必须提供不依赖手机号的恢复方式。比较稳妥的方案是：注册成功后，立即提示用户保存一串恢复密钥或助记词，下次在新设备上输入恢复密钥即可迁移账号。

需要强调的是，恢复密钥一旦丢失，账号几乎无法找回。这是因为没有手机号作为中心化身份锚点，服务端无法验证“你是你”。这属于无手机号模式固有的安全边界，产品设计上必须把风险提示放在注册流程的显眼位置，否则后续的用户数据丢失投诉量会非常可怕。

作为开发者在做类似功能时，一定要在注册流程里加入“备份恢复码”的强提醒。很多产品就是因为恢复码藏得太深，导致用户真的丢设备后无法找回账号，客服压力非常大。

4.4 反滥用引擎调整

反滥用是隐藏在工作台后面的核心工作。Signal 现在依赖手机号做风控：

• 同一手机号注册次数限制；
• 验证码发送频率限制；
• 对可疑号码段进行拦截；
• 对注册 IP 做风险评分。

去掉手机号之后，风控逻辑必须重写。可能的策略包括：

• 设备指纹：记录设备硬件信息，限制同一设备注册次数；
• IP 信誉：对注册来源 IP 做风险评估；
• 购买凭证真实性：利用支付通道的高可信度来拦截低成本滥用；
• 行为分析：记录注册之后的交互行为，识别批量注册的机器特征。

可以看到，风控策略从“手机号成本”转移到了“支付成本 + 设备指纹 + 行为分析”的组合上。对 Signal 来说，这是在降低用户隐私暴露和维持社区安全之间找到的一个新平衡点。

4.5 数据库表设计示意

为了直观展示“手机号注册”和“付费免手机号注册”如何共存，下面给出一个简化版的数据库表结构：

-- 账号表 CREATE TABLE signal_accounts ( account_id UUID PRIMARY KEY, username VARCHAR(64) UNIQUE, phone_number VARCHAR(20) UNIQUE, is_no_phone BOOLEAN DEFAULT FALSE, recovery_key_hash TEXT, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); -- 购买凭证表 CREATE TABLE purchase_receipts ( receipt_id UUID PRIMARY KEY, account_id UUID REFERENCES signal_accounts(account_id), store_receipt TEXT UNIQUE NOT NULL, store_type VARCHAR(16) NOT NULL, -- apple / google verified_at TIMESTAMP WITH TIME ZONE, used_at TIMESTAMP WITH TIME ZONE );

设计思路说明：

• is_no_phone字段用于区分账号是否绑定手机号；
• phone_number允许为空，配合唯一索引可以保证非空手机号不重复；
• purchase_receipts表记录购买凭证的使用情况，防止同一凭证重复绑定；
• store_receipt字段保存应用商店返回的购买凭证，应该加密存储，避免泄露。

这段 SQL 只是为了演示字段关系，真实 Signal 系统的表结构会比这复杂得多，但它能帮你理解：免手机号不是把字段设置为 nullable，而是一套完整的关联数据结构。

5. 对开发者的启示：认证系统如何设计“多策略并存”

Signal 这个转向，本质上是从“唯一认证要素”转向“可替代认证要素”。这对所有做用户系统的开发者都有参考价值。

5.1 认证要素要覆盖两种成本

在设计注册功能时，我们需要考虑两类门槛：

• 获取成本：手机号需要真实 SIM 卡，支付需要真实资金；
• 验证成本：短信验证码、邮箱确认、支付回调等。

过去很多产品喜欢把手机号作为唯一注册要素，因为实现简单、风控成本低。但代价是用户隐私暴露。更现代的设计是允许用户从多种验证方式中任选一种，比如手机号加验证码、邮箱加验证链接、付费加购买凭证。

关键点在于：不同验证方式的隐私影响不同，风控强度也应不同。对隐私要求高的用户，让他们通过一次性付费承担一部分成本；对普通用户，继续保留手机号注册的低门槛路径。这样既保留了便捷性，又堵住了免费匿名注册的滥用漏洞。

5.2 一个策略模式的简单示例

用 Python 写一个简单的策略模式示例，演示“手机号注册”和“付费免手机号注册”如何并存：

class RegistrationStrategy: def register(self, account_data: dict) -> str: raise NotImplementedError class PhoneRegistration(RegistrationStrategy): def register(self, account_data: dict) -> str: phone = account_data["phone"] code = account_data["sms_code"] if not verify_sms_code(phone, code): raise ValueError("验证码错误") return create_account(phone=phone) class PaymentRegistration(RegistrationStrategy): def register(self, account_data: dict) -> str: token = account_data["purchase_token"] if not verify_store_receipt(token): raise ValueError("购买凭证无效") if receipt_already_used(token): raise ValueError("购买凭证已使用") account_id = create_account(phone=None) bind_receipt(account_id, token) return account_id def get_registration_strategy(user_choice: str) -> RegistrationStrategy: if user_choice == "phone": return PhoneRegistration() elif user_choice == "payment": return PaymentRegistration() else: raise ValueError("不支持的注册方式")

核心思想是：注册方式被抽象成策略，每种策略自己处理验证逻辑和风控逻辑，上层业务无需关心用户从哪个通道注册。后续如果新增邮箱注册或生物识别注册，只需要增加新的策略类，不影响已有代码。

需要说明的是，verify_sms_code、verify_store_receipt、create_account都是业务抽象函数，真正开发时需要对接具体的短信服务商、应用商店服务端 API 和用户账号库。

6. 关于 Signal 一次性付费的常见问题

7. 后续值得关注的技术点

这篇文章借着 Signal 的规划，把“免手机号注册”背后的产品和工程逻辑拆开了一遍。如果你对账号体系设计感兴趣，可以继续关注以下几个方向：

• Signal Protocol 的密钥轮换与会话恢复机制；
• 去中心化身份方案中的密钥找回设计；
• 移动端内购凭证验证在 Apple 和 Google 双平台下的差异处理；
• 反滥用系统中的设备指纹与 IP 信誉模型；
• 端到端加密应用中联系人发现的安全设计。

对普通用户来说，这个功能的意义在于：隐私保护的门槛从“有一个手机号”降低到了“愿意为隐私付一小笔费用”。对开发者来说，更值得记录的是 Signal 的设计决策：把身份验证从“唯一绑定”改成“多选一”，用支付成本替代身份信息，在隐私保护和反滥用之间寻找平衡。

如果让我给一个工程上的建议：在产品里增加“免手机号 / 免邮箱”注册时，一定要先想清楚替代验证方式是否具备足够的反滥用成本。免费开放没有门槛的匿名注册，几乎一定会被机器注册和垃圾流量盯上。Signal 用“一次性付费”做门槛，本质上是在用经济成本约束恶意行为，这个思路值得所有做大用户量产品的团队参考。