最近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 当前的注册流程可以简化成以下几步用户在客户端输入自己的手机号。服务端调用短信通道或语音通道向该号码发送验证码。用户输入验证码客户端生成密钥对并把公钥注册到服务端。服务端记录手机号与账号标识的绑定关系。用户后续登录、消息投递都基于这个账号体系运行。整个流程看起来并不复杂但手机号在系统里承担了四件事身份唯一性一个手机号在 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、支付宝、微信支付那“免手机号注册”就失去了意义——支付渠道掌握着真实姓名、支付账户、银行卡等信息隐私级别比手机号还要低。所以真正可行的方案是走应用商店内购通道或者购买匿名兑换码。大致流程如下用户从 App Store 或者 Google Play 购买“免手机号注册”虚拟商品应用商店返回一个购买凭证purchase token 或 receipt客户端把这个凭证发送给 Signal 服务端服务端调用应用商店的验证接口确认凭证合法验证通过后为该 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 注册与认证链路改造无手机号账号的注册流程大致可以设计成用户点击“不使用手机号注册”客户端引导用户完成一次性购买拿到购买凭证客户端把购买凭证发送给服务端服务端校验凭证并创建账号为账号生成一个独立的恢复密钥用于换设备时恢复数据。和手机号注册相比唯一被替换掉的是“验证码”这一步。之前由短信验证码完成真人验证现在由支付凭证完成。但后续的认证链路发生了变化手机号注册的用户可以随时用手机号重新登录而无手机号用户则需要依赖别的凭证。可能的替代验证方案包括设置独立用户名绑定密码或恢复码生成一组助记词使用恢复密钥Recovery Key。这种设计在去中心化产品、加密钱包中很常见Signal 如果想长期支持无手机号账号大概率会参考类似方案来设计密钥找回流程。4.2 联系人发现机制的替代方案手机号注册有一个隐形的优势用户不需要主动告知自己的账号标识。只要通讯录里保存了好友的手机号而好友也注册了 SignalApp 就会通过通讯录哈希匹配自动显示出联系人。无手机号账号享受不到这种便利。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(phonephone) 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(phoneNone) 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 一次性付费的常见问题问题说明这个功能上线了吗还没有。Signal 官方公开讨论过这一方向但尚未公布正式上线时间。是一次性付费还是订阅按官方释放的信息倾向一次性付费具体以正式上线为准。付费后就能完全隐藏手机号吗如果按无手机号注册设计Signal 服务端不会记录手机号聊天中也不会向对方显示手机号。现有手机号用户会受影响吗大概率不会。现有用户仍可继续使用手机号登录付费选项目前更像面向新用户的替代入口。不付费还能注册吗可以只要提供手机号即可。付费只是“免手机号”这种注册方式的验证门槛。没有手机号好友怎么找到我可以通过 Signal 用户名、二维码、邀请链接等方式添加。支付会泄露我的真实身份吗走应用商店内购时支付平台掌握购买者身份但 Signal 服务端只验证购买凭证不直接获取购买者的实名信息。对开发者有什么参考价值它展示了“多验证方式并存、成本门槛替代身份绑定”的账号体系设计思路。7. 后续值得关注的技术点这篇文章借着 Signal 的规划把“免手机号注册”背后的产品和工程逻辑拆开了一遍。如果你对账号体系设计感兴趣可以继续关注以下几个方向Signal Protocol 的密钥轮换与会话恢复机制去中心化身份方案中的密钥找回设计移动端内购凭证验证在 Apple 和 Google 双平台下的差异处理反滥用系统中的设备指纹与 IP 信誉模型端到端加密应用中联系人发现的安全设计。对普通用户来说这个功能的意义在于隐私保护的门槛从“有一个手机号”降低到了“愿意为隐私付一小笔费用”。对开发者来说更值得记录的是 Signal 的设计决策把身份验证从“唯一绑定”改成“多选一”用支付成本替代身份信息在隐私保护和反滥用之间寻找平衡。如果让我给一个工程上的建议在产品里增加“免手机号 / 免邮箱”注册时一定要先想清楚替代验证方式是否具备足够的反滥用成本。免费开放没有门槛的匿名注册几乎一定会被机器注册和垃圾流量盯上。Signal 用“一次性付费”做门槛本质上是在用经济成本约束恶意行为这个思路值得所有做大用户量产品的团队参考。 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 当前的注册流程可以简化成以下几步用户在客户端输入自己的手机号。服务端调用短信通道或语音通道向该号码发送验证码。用户输入验证码客户端生成密钥对并把公钥注册到服务端。服务端记录手机号与账号标识的绑定关系。用户后续登录、消息投递都基于这个账号体系运行。整个流程看起来并不复杂但手机号在系统里承担了四件事身份唯一性一个手机号在 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、支付宝、微信支付那“免手机号注册”就失去了意义——支付渠道掌握着真实姓名、支付账户、银行卡等信息隐私级别比手机号还要低。所以真正可行的方案是走应用商店内购通道或者购买匿名兑换码。大致流程如下用户从 App Store 或者 Google Play 购买“免手机号注册”虚拟商品应用商店返回一个购买凭证purchase token 或 receipt客户端把这个凭证发送给 Signal 服务端服务端调用应用商店的验证接口确认凭证合法验证通过后为该 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 注册与认证链路改造无手机号账号的注册流程大致可以设计成用户点击“不使用手机号注册”客户端引导用户完成一次性购买拿到购买凭证客户端把购买凭证发送给服务端服务端校验凭证并创建账号为账号生成一个独立的恢复密钥用于换设备时恢复数据。和手机号注册相比唯一被替换掉的是“验证码”这一步。之前由短信验证码完成真人验证现在由支付凭证完成。但后续的认证链路发生了变化手机号注册的用户可以随时用手机号重新登录而无手机号用户则需要依赖别的凭证。可能的替代验证方案包括设置独立用户名绑定密码或恢复码生成一组助记词使用恢复密钥Recovery Key。这种设计在去中心化产品、加密钱包中很常见Signal 如果想长期支持无手机号账号大概率会参考类似方案来设计密钥找回流程。4.2 联系人发现机制的替代方案手机号注册有一个隐形的优势用户不需要主动告知自己的账号标识。只要通讯录里保存了好友的手机号而好友也注册了 SignalApp 就会通过通讯录哈希匹配自动显示出联系人。无手机号账号享受不到这种便利。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(phonephone) 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(phoneNone) 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 一次性付费的常见问题问题说明这个功能上线了吗还没有。Signal 官方公开讨论过这一方向但尚未公布正式上线时间。是一次性付费还是订阅按官方释放的信息倾向一次性付费具体以正式上线为准。付费后就能完全隐藏手机号吗如果按无手机号注册设计Signal 服务端不会记录手机号聊天中也不会向对方显示手机号。现有手机号用户会受影响吗大概率不会。现有用户仍可继续使用手机号登录付费选项目前更像面向新用户的替代入口。不付费还能注册吗可以只要提供手机号即可。付费只是“免手机号”这种注册方式的验证门槛。没有手机号好友怎么找到我可以通过 Signal 用户名、二维码、邀请链接等方式添加。支付会泄露我的真实身份吗走应用商店内购时支付平台掌握购买者身份但 Signal 服务端只验证购买凭证不直接获取购买者的实名信息。对开发者有什么参考价值它展示了“多验证方式并存、成本门槛替代身份绑定”的账号体系设计思路。7. 后续值得关注的技术点这篇文章借着 Signal 的规划把“免手机号注册”背后的产品和工程逻辑拆开了一遍。如果你对账号体系设计感兴趣可以继续关注以下几个方向Signal Protocol 的密钥轮换与会话恢复机制去中心化身份方案中的密钥找回设计移动端内购凭证验证在 Apple 和 Google 双平台下的差异处理反滥用系统中的设备指纹与 IP 信誉模型端到端加密应用中联系人发现的安全设计。对普通用户来说这个功能的意义在于隐私保护的门槛从“有一个手机号”降低到了“愿意为隐私付一小笔费用”。对开发者来说更值得记录的是 Signal 的设计决策把身份验证从“唯一绑定”改成“多选一”用支付成本替代身份信息在隐私保护和反滥用之间寻找平衡。如果让我给一个工程上的建议在产品里增加“免手机号 / 免邮箱”注册时一定要先想清楚替代验证方式是否具备足够的反滥用成本。免费开放没有门槛的匿名注册几乎一定会被机器注册和垃圾流量盯上。Signal 用“一次性付费”做门槛本质上是在用经济成本约束恶意行为这个思路值得所有做大用户量产品的团队参考。