很多用过 Signal 的人都有一个矛盾心态一方面认可它是目前端到端加密做得比较彻底的开源通讯工具另一方面又对“注册必须填手机号”这一步感到不安。手机号是最强的身份标识也是最长效的隐私关联项。你换了运营商、换了 SIM 卡账号找回要依赖它你不想被通讯录里的人发现自己也要靠它做权衡。所以当 Signal 被曝出可能正在开发“付费免手机号注册”选项时这则消息在加密通讯圈里引起的关注远不止“多了一个会员入口”这么简单。它真正指向的问题是一个把手机号当作身份锚点的加密通讯系统在去掉手机号之后要怎么保证账户不被批量滥用、密钥可以被安全找回、用户之间仍然可以建立可信的联系换句话说手机号在 Signal 的账户体系里做了很多隐形工作现在要把这个“地基”换成另一套机制后续的账户安全和产品流程都要跟着改。这篇文章会从产品形态、技术路径、账户安全、反滥用设计和工程落地几个角度拆解这次变化。如果你在做隐私类产品、聊天应用或用户账户体系这篇文章也值得看完因为 Signal 遇到的问题是所有想“去手机号化”的产品都会遇到的问题。1. 这篇文章真正要解决的问题先问一个问题Signal 为什么要考虑“付费免手机号注册”要理解这一点先得理解手机号在 Signal 里不只是“一个注册字段”。它承担了至少四个职能注册凭证证明“你不是一个自动化注册的机器人”。登录凭证换设备时通过短信验证码或语音验证找回旧身份。通讯录匹配通过手机号发现好友这是 Signal 建立社交图谱的基础。反滥用锚点申请一个手机号有成本和身份门槛垃圾账户注册者很难无限量申请。这四个职能里第 1、2、4 项是安全相关第 3 项是产品功能。如果去掉手机号前三项都要重新设计第四项要找到替代品。而“付费”恰好可以替代一部分防滥用职能愿意为一个匿名账户付钱的人批量注册成本会显著上升。但这里有一个很容易被误读的点付费免手机号注册不等于匿名注册。付费渠道本身可能绑定信用卡、App Store 或 Google Play 账号这些信息同样可以关联到真实身份。Signal 能做的只是让“手机号”这个信息不再出现在账户体系里让 Signal 服务端不再知道你绑定的号码。所以这篇文章要讨论的核心问题是零手机号账户的产品流程应该怎么设计账户安全和找回机制会发生哪些变化反滥用体系如何用付费门槛和其他手段重新搭建这套设计对开发者和隐私产品有什么借鉴意义无论 Signal 最终是否上线这个功能、以什么价格上线这套问题本身对开发者很有价值。2. 手机号为什么是 Signal 账户体系的核心在讨论“去掉手机号”之前先要理解手机号在 Signal 里为什么一直被保留。2.1 手机号是“身份锚点”在 Signal 的信任模型里手机号是账户的唯一标识。你在新手机上输入手机号收到验证码就能恢复旧账户你把手机号告诉朋友朋友就能通过通讯录匹配找到你。Signal 的很多安全设计比如 Safety Number 校验、联系人锁定都建立在“这个手机号对应一个确定性身份”的前提上。手机号作为锚点的好处是稳定、唯一、可验证。坏处是它同时关联了真实身份在很多地区手机号需要实名办理运营商和监管方可以看到号码归属人。即使 Signal 本身拿不到你的通讯录内容它也能知道每个账户对应的手机号是什么这本身就是一种元数据关联。去掉手机号之后Signal 的第一个难题就是用什么来当新用户的第一身份标识是随机生成的 ID是公钥指纹是一次性恢复码这个问题不解决后面所有流程都推进不下去。2.2 手机号是“通讯录匹配”的唯一索引另一个容易被忽视的是Signal 的社交关系建立在手机号之上。你和朋友能互相发现是因为你的手机通讯录里存了对方的号码而 Signal 能用安全的方式来比对号码。如果新账户没有手机号Signal 需要决定两件事无手机号账户如何被朋友添加无手机号账户能否被通讯录中的联系人发现这会直接影响产品体验。如果无手机号账户只能通过二维码或链接添加它的传播路径就和传统号码模式完全不同。新增联系人、群聊邀请、跨设备同步这些流程可能都要重构。2.3 为什么“免费匿名注册”极难实现看到这里你可能会想直接把手机号去掉改成用户名或邮箱不就行了吗为什么一定要“付费”因为在隐私类产品里免费匿名账户 可以任意注册几乎等于给垃圾信息攻击开了一扇门。攻击者可以写脚本批量注册海量账户用这些账户发送垃圾消息、加入群组、探测其他用户的在线状态甚至发起垃圾举报。手机号至少提供了一个“物理成本门槛”批量注册需要大量 SIM 卡而这既花钱又受制于运营商规则。付费门槛就是这个物理成本门槛的替代品。通过一次付费来换取一个匿名账户名额本质上是在用价格来约束注册频率。一个无法被手机号追踪的账户如果连一分钱都不花就有大量滥用空间如果每次注册都要付一笔钱垃圾账户的运营成本就会上升。不过这里仍然要强调付费是“阻尼器”不是“防火墙”。依赖支付渠道做验证也会有退款、礼品卡、黑产代充等绕过方式工程上还需要叠加设备指纹、行为检测、邀请链限制等策略。3. “付费免手机号注册”的产品路径推断从现有公开信息看Signal 正在研究“付费 免手机号”这个组合具体是何种形态还没有官方细节。这里基于行业常见做法列出三种可能的产品路径供开发者和产品经理参考。3.1 路径 A付费换取“匿名注册名额”仍保留手机号作为可选恢复方式这是一种最稳妥的渐进设计。用户选择匿名注册后先进入付费页面支付完成得到一份临时凭证再用凭证创建账户。系统生成一个随机 ID不要求用户填手机号但用户在设置里仍然可以“补充绑定手机号”用于未来找回。这种设计的好处是改动范围小。找回流程、防滥用策略、联系人匹配仍然可以复用原有手机号能力只是注册环节多了一个“非必填”分支。坏处是它没有彻底解决“服务端知道手机号”的问题只是给了用户一个不提供手机号的选择。3.2 路径 B完全无手机号账户以恢复码作为身份凭证在这种路径里Signal 会一次性生成一组高强度恢复码要求用户把它抄写下来或存入密码管理器。恢复码是唯一能恢复账户的凭证。服务端不保存手机号也不保存恢复码明文只保存恢复码哈希。这套方案最符合“真正去掉手机号”的产品叙事但工程难度最高。用户一旦丢失恢复码且没有绑定备用邮箱或设备账户就找不回来了。而且恢复码的生成、展示、确认、备份流程每一步都关系到账户是否可恢复用户体验很难做。3.3 路径 C订阅制匿名层把付费做成会员权益还有可能是把免手机号注册做成付费会员的权益之一而不是一次性买断。这样既能形成持续收入又能通过订阅的扣费行为建立另一个身份锚点Signal 服务端不知道你是谁但支付平台知道。这种设计对产品团队更友好因为它把商业化变成了一个订阅模型。但对用户来说匿名账户需要“按月续费”会带来新的心理门槛如果哪个月忘记续费账户会怎样这又回到账户状态管理的复杂度。从现有公开信息看Signal 最终可能选择的是路径 A 或 B 的变体也可能直接在现有注册流程上增加一个“使用支付方式跳过手机号”的选项。具体方案要等官方发布。但不管选哪条路下面这些技术问题都是一定要解决的。4. 无手机号账户的技术流程与代码演示下面用几个模拟代码演示“无手机号付费注册”的账户体系设计。注意这些代码不是 Signal 官方实现而是为了帮助理解流程和关键设计点。4.1 注册流程状态机无手机号注册最核心的变化是流程变长从“填手机号 - 收验证码 - 创建账户”变成了“选择匿名注册 - 付费 - 生成密钥 - 展示恢复码 - 确认备份 - 创建身份”。后端可以用一个状态机来控制。# 文件路径demo/registration_flow.py # 演示代码模拟无手机号付费注册流程的状态机非 Signal 官方实现 class RegistrationState: START start PAYMENT_REQUIRED payment_required PAYMENT_VERIFYING payment_verifying KEY_GENERATION key_generation RECOVERY_SHOWN recovery_shown RECOVERY_CONFIRMED recovery_confirmed IDENTITY_CREATED identity_created class RegistrationFlow: def __init__(self): self.state RegistrationState.START def handle_event(self, event: str) - str: if self.state RegistrationState.START and event choose_anonymous: self.state RegistrationState.PAYMENT_REQUIRED elif self.state RegistrationState.PAYMENT_REQUIRED and event payment_received: self.state RegistrationState.PAYMENT_VERIFYING elif self.state RegistrationState.PAYMENT_VERIFYING and event payment_verified: self.state RegistrationState.KEY_GENERATION elif self.state RegistrationState.KEY_GENERATION and event keys_ready: self.state RegistrationState.RECOVERY_SHOWN elif self.state RegistrationState.RECOVERY_SHOWN and event recovery_backed_up: self.state RegistrationState.IDENTITY_CREATED else: raise ValueError(f非法状态迁移: {self.state} - {event}) return self.state关键点在于每一步状态迁移都必须有明确的触发器。用户付费后不是直接创建账户而是先进入支付验证再生成密钥和恢复码。这是因为无手机号账户没有“短信验证码”这个二次确认手段所有环节必须靠事件驱动否则很容易出现“钱付了账户没创建成功”的问题。4.2 恢复码生成与存储无手机号账户的生命线就是恢复码。恢复码需要满足三个条件高熵、便于抄写、服务端不可恢复明文。# 文件路径demo/recovery_code.py # 演示代码生成高强度恢复码并计算服务端存储哈希 import secrets import hashlib def generate_recovery_code() - str: # 32 字节随机数256 bit 熵暴力猜测成本极高 raw secrets.token_bytes(32) hex_code raw.hex().upper() # 每 8 位一组方便用户抄写和输入 grouped -.join(hex_code[i:i8] for i in range(0, len(hex_code), 8)) return grouped def hash_recovery_code(code: str) - str: # 服务端只保存 SHA-256 哈希不保存明文 # 实际生产环境建议使用带盐的慢哈希比如 scrypt/argon2 return hashlib.sha256(code.encode(utf-8)).hexdigest() if __name__ __main__: code generate_recovery_code() print(恢复码:, code) print(服务端存储:, hash_recovery_code(code))这段代码在真实项目中要注意两个问题。第一服务端存储建议用 argon2 或 scrypt 这种慢哈希而不是纯 SHA-256。第二恢复码展示给用户之后客户端要引导用户完成“确认抄写”步骤防止用户直接跳过备份。恢复码一旦丢失无手机号账户可能就永久失去访问能力这个 UX 设计必须谨慎。4.3 服务端防滥用校验去掉手机号后服务端在创建账户前需要增加支付凭证校验和速率限制。// 文件路径demo/AnonSignupService.java // 演示代码无手机号注册时的服务端防滥用校验非 Signal 官方实现 public class AnonSignupService { private final PaymentVerifier paymentVerifier; private final RateLimiter rateLimiter; private final IdentityStore identityStore; public AnonSignupService(PaymentVerifier paymentVerifier, RateLimiter rateLimiter, IdentityStore identityStore) { this.paymentVerifier paymentVerifier; this.rateLimiter rateLimiter; this.identityStore identityStore; } public SignupResult registerAnonymous(String paymentToken, String deviceFingerprint) { // 1. 同一个设备指纹在同一时间窗口内只能注册有限次数 if (!rateLimiter.tryAcquire(deviceFingerprint)) { return SignupResult.tooManyRequests(); } // 2. 校验支付凭证防止伪造支付回调 if (!paymentVerifier.verify(paymentToken)) { return SignupResult.paymentRejected(); } // 3. 创建匿名身份不绑定手机号 AnonymousIdentity identity identityStore.createAnonymousIdentity(); // 4. 生成一次性恢复码返回给客户端 String recoveryCode identity.generateRecoveryCode(); return SignupResult.success(identity.getId(), recoveryCode); } }这里的关键设计是“把支付也当成反滥用的一环”。但要注意支付凭证验证必须在服务端做不能只依赖客户端传来的支付结果。生产环境还要处理支付回调的幂等性遇到重复回调不能重复创建账户。5. 去掉手机号之后账户安全工作流会发生什么无手机号注册表面上只是把“填手机号”这一步骤改成了“付费”但整个账户安全体系都会因此产生连锁反应。下面按安全工作流逐层拆解。5.1 身份恢复从“验证码找回”变成“恢复码找回”原先用户换手机只需要短信验证码就能找回账户。这个流程对用户很友好安全强度取决于 SIM 卡是否被保护。无手机号账户没有短信通道找回只能靠恢复码或者提供额外的备用邮箱、备用设备授权。这意味着产品团队必须做两件事一是把恢复码的备份流程做到极致二是提供可选的备用联系方式。否则“没有手机号”的状态很容易变成“账户无法找回”的隐患。5.2 信任模型从“号码即身份”变成“公钥即身份”在 Signal 原有的模型里手机号是公开可见的身份标识两个人的信任关系可以建立在号码匹配上。去掉手机号后账号信息里可能只剩一个随机 ID 和公钥指纹。这对隐私更友好但用户之间如何验证“对方确实是那个人”会更难安全码校验的展示方式也要重新设计。5.3 反滥用从“SIM 卡成本”变成“支付成本 设备指纹 行为检测”手机号天然有注册成本去掉手机号后开发者需要叠加多层策略设备指纹识别同一台设备是否尝试重复注册。支付风控识别礼品卡、盗刷、代充的黑产链。行为特征分析注册后的使用行为比如是否在短时间内大量发消息。邀请限制限制无手机号账户的邀请能力防止灰产批量扩散。这些策略单独看都不完美组合起来才能形成有效的阻尼。从现有信息看Signal 如果真的上线付费免手机号注册大概率会把这几种手段一起用上。5.4 合规与审计需要重新定义“用户标识”很多地区对即时通讯软件有实名或备案要求留存“手机号”也是平台审计的重要手段。无手机号账户上线后运营团队必须重新定义“用户标识”当用户申诉、账号被盗、配合执法调查时唯一标识是什么如果只有一个随机 ID平台如何定位到具体账户这不仅是产品决策也是法务和合规决策。6. 对开发者的启示如何设计不依赖手机号的账户体系Signal 这次尝试的最大价值不是某个功能本身而是给所有做账户体系的团队提供了一个现实案例手机号并不是唯一可选的身份源。下面这些设计思路在任何需要“降级手机号依赖”的产品里都适用。6.1 把“身份”和“认证方式”分离很多产品的账户体系把手机号既当作“身份标识”又当作“登录凭证”和“找回凭证”。这是最省事的设计但一旦要支持无手机号用户就会陷入重复绑定、账号合并、找回困难等问题。更稳妥的做法是系统内部使用自增 ID 或 UUID 作为主身份标识手机号只是其中一个登录因子。这样未来想加“邮箱登录”“硬件密钥登录”“无手机号注册”时只需要新增一种认证因子不需要重构用户表。6.2 恢复码要设计成“多备份可验证”凡是涉及敏感资产的账户都应该在注册时给用户提供恢复码并引导用户至少保存两份比如一份抄写在纸上、一份放密码管理器。产品还要提供“恢复码验证”的测试流程让用户确认自己保存的恢复码确实有效而不是等到账户丢了才发现抄错了。6.3 风控要分层不能依赖单一门槛如果你在做一个匿名或弱实名产品付费门槛可以降低垃圾注册但不要指望它解决所有问题。更成熟的方案是把注册成本分成多层新账户创建后的前 N 天限制部分操作设备指纹异常时提高验证要求出现群发、短时大量添加好友等行为时直接进入人工审核。6.4 灰度发布时要设计“退出路径”去手机号化是对已有用户习惯的破坏性改动。即使 Signal 上线了免手机号注册也可以先把新用户放进单独的注册通道里观察找回率、滥用率、付费转化率再决定是否向全量开放。对开发者来说任何账户体系的重大变更都要考虑现有用户能不能平滑过渡新用户是不是真的比旧用户多如果数据不理想怎么回滚到保持手机号方案7. 常见问题与排查思路Signal 官方尚未公开无手机号注册的详细支持文档以下问题来自各类账户体系的共性问题可用来建立排查思路。问题现象可能原因排查方式解决方案注册后一直提示“验证处理中pending”风控进入人工审核或二次验证未完成检查注册邮箱/短信的验证链接查看账户状态页按指引完成二次验证长时间未响应再联系支持渠道登录时提示 access denied账户被风控标记、设备环境异常、多次验证失败核对网络环境和设备指纹检查恢复码输入是否正确更换可信网络重试必要时提交账户申诉账户被锁定account locked短时间内多次输错验证码安全策略自动锁定查看账户状态页的锁定倒计时检查是否有解锁邮件等待自动解锁走身份恢复流程恢复码丢失注册时未备份或备份介质损坏检查是否绑定过备用邮箱/备用设备用备用方式找回若完全没有绑定只能重建账户付费成功但账户未创建支付回调延迟、幂等逻辑缺陷、客户端未刷新状态查询支付订单状态服务端检查支付回调日志手动补发账户创建请求修复幂等逻辑当用户遇到这些问题时最有效的排查路径是先看是“注册阶段”还是“登录阶段”的问题再看是“身份验证失败”还是“风控拦截”然后针对性查看日志。不要一股脑让用户重装应用。8. 趋势判断从“手机号即身份”到“可分离账户身份”Signal 的付费免手机号注册实验放在更长的时间轴上看并不是孤例。近几年整个行业都在尝试降低对手机号的依赖Apple 的“隐藏邮件地址”功能让用户可以用随机邮箱接收邮件把真实邮箱和 App 隔离开。Passkey 正在推动人们用设备生物识别代替密码和验证码登录因子变成“设备上的一把私钥”而不是“你拥有的一个号码”。很多开发者也在把账户系统从“手机号 验证码”往“邮箱 密码 多因素认证”迁移虽然 Signal付费免手机号注册：从手机号到可分离的账户身份
很多用过 Signal 的人都有一个矛盾心态一方面认可它是目前端到端加密做得比较彻底的开源通讯工具另一方面又对“注册必须填手机号”这一步感到不安。手机号是最强的身份标识也是最长效的隐私关联项。你换了运营商、换了 SIM 卡账号找回要依赖它你不想被通讯录里的人发现自己也要靠它做权衡。所以当 Signal 被曝出可能正在开发“付费免手机号注册”选项时这则消息在加密通讯圈里引起的关注远不止“多了一个会员入口”这么简单。它真正指向的问题是一个把手机号当作身份锚点的加密通讯系统在去掉手机号之后要怎么保证账户不被批量滥用、密钥可以被安全找回、用户之间仍然可以建立可信的联系换句话说手机号在 Signal 的账户体系里做了很多隐形工作现在要把这个“地基”换成另一套机制后续的账户安全和产品流程都要跟着改。这篇文章会从产品形态、技术路径、账户安全、反滥用设计和工程落地几个角度拆解这次变化。如果你在做隐私类产品、聊天应用或用户账户体系这篇文章也值得看完因为 Signal 遇到的问题是所有想“去手机号化”的产品都会遇到的问题。1. 这篇文章真正要解决的问题先问一个问题Signal 为什么要考虑“付费免手机号注册”要理解这一点先得理解手机号在 Signal 里不只是“一个注册字段”。它承担了至少四个职能注册凭证证明“你不是一个自动化注册的机器人”。登录凭证换设备时通过短信验证码或语音验证找回旧身份。通讯录匹配通过手机号发现好友这是 Signal 建立社交图谱的基础。反滥用锚点申请一个手机号有成本和身份门槛垃圾账户注册者很难无限量申请。这四个职能里第 1、2、4 项是安全相关第 3 项是产品功能。如果去掉手机号前三项都要重新设计第四项要找到替代品。而“付费”恰好可以替代一部分防滥用职能愿意为一个匿名账户付钱的人批量注册成本会显著上升。但这里有一个很容易被误读的点付费免手机号注册不等于匿名注册。付费渠道本身可能绑定信用卡、App Store 或 Google Play 账号这些信息同样可以关联到真实身份。Signal 能做的只是让“手机号”这个信息不再出现在账户体系里让 Signal 服务端不再知道你绑定的号码。所以这篇文章要讨论的核心问题是零手机号账户的产品流程应该怎么设计账户安全和找回机制会发生哪些变化反滥用体系如何用付费门槛和其他手段重新搭建这套设计对开发者和隐私产品有什么借鉴意义无论 Signal 最终是否上线这个功能、以什么价格上线这套问题本身对开发者很有价值。2. 手机号为什么是 Signal 账户体系的核心在讨论“去掉手机号”之前先要理解手机号在 Signal 里为什么一直被保留。2.1 手机号是“身份锚点”在 Signal 的信任模型里手机号是账户的唯一标识。你在新手机上输入手机号收到验证码就能恢复旧账户你把手机号告诉朋友朋友就能通过通讯录匹配找到你。Signal 的很多安全设计比如 Safety Number 校验、联系人锁定都建立在“这个手机号对应一个确定性身份”的前提上。手机号作为锚点的好处是稳定、唯一、可验证。坏处是它同时关联了真实身份在很多地区手机号需要实名办理运营商和监管方可以看到号码归属人。即使 Signal 本身拿不到你的通讯录内容它也能知道每个账户对应的手机号是什么这本身就是一种元数据关联。去掉手机号之后Signal 的第一个难题就是用什么来当新用户的第一身份标识是随机生成的 ID是公钥指纹是一次性恢复码这个问题不解决后面所有流程都推进不下去。2.2 手机号是“通讯录匹配”的唯一索引另一个容易被忽视的是Signal 的社交关系建立在手机号之上。你和朋友能互相发现是因为你的手机通讯录里存了对方的号码而 Signal 能用安全的方式来比对号码。如果新账户没有手机号Signal 需要决定两件事无手机号账户如何被朋友添加无手机号账户能否被通讯录中的联系人发现这会直接影响产品体验。如果无手机号账户只能通过二维码或链接添加它的传播路径就和传统号码模式完全不同。新增联系人、群聊邀请、跨设备同步这些流程可能都要重构。2.3 为什么“免费匿名注册”极难实现看到这里你可能会想直接把手机号去掉改成用户名或邮箱不就行了吗为什么一定要“付费”因为在隐私类产品里免费匿名账户 可以任意注册几乎等于给垃圾信息攻击开了一扇门。攻击者可以写脚本批量注册海量账户用这些账户发送垃圾消息、加入群组、探测其他用户的在线状态甚至发起垃圾举报。手机号至少提供了一个“物理成本门槛”批量注册需要大量 SIM 卡而这既花钱又受制于运营商规则。付费门槛就是这个物理成本门槛的替代品。通过一次付费来换取一个匿名账户名额本质上是在用价格来约束注册频率。一个无法被手机号追踪的账户如果连一分钱都不花就有大量滥用空间如果每次注册都要付一笔钱垃圾账户的运营成本就会上升。不过这里仍然要强调付费是“阻尼器”不是“防火墙”。依赖支付渠道做验证也会有退款、礼品卡、黑产代充等绕过方式工程上还需要叠加设备指纹、行为检测、邀请链限制等策略。3. “付费免手机号注册”的产品路径推断从现有公开信息看Signal 正在研究“付费 免手机号”这个组合具体是何种形态还没有官方细节。这里基于行业常见做法列出三种可能的产品路径供开发者和产品经理参考。3.1 路径 A付费换取“匿名注册名额”仍保留手机号作为可选恢复方式这是一种最稳妥的渐进设计。用户选择匿名注册后先进入付费页面支付完成得到一份临时凭证再用凭证创建账户。系统生成一个随机 ID不要求用户填手机号但用户在设置里仍然可以“补充绑定手机号”用于未来找回。这种设计的好处是改动范围小。找回流程、防滥用策略、联系人匹配仍然可以复用原有手机号能力只是注册环节多了一个“非必填”分支。坏处是它没有彻底解决“服务端知道手机号”的问题只是给了用户一个不提供手机号的选择。3.2 路径 B完全无手机号账户以恢复码作为身份凭证在这种路径里Signal 会一次性生成一组高强度恢复码要求用户把它抄写下来或存入密码管理器。恢复码是唯一能恢复账户的凭证。服务端不保存手机号也不保存恢复码明文只保存恢复码哈希。这套方案最符合“真正去掉手机号”的产品叙事但工程难度最高。用户一旦丢失恢复码且没有绑定备用邮箱或设备账户就找不回来了。而且恢复码的生成、展示、确认、备份流程每一步都关系到账户是否可恢复用户体验很难做。3.3 路径 C订阅制匿名层把付费做成会员权益还有可能是把免手机号注册做成付费会员的权益之一而不是一次性买断。这样既能形成持续收入又能通过订阅的扣费行为建立另一个身份锚点Signal 服务端不知道你是谁但支付平台知道。这种设计对产品团队更友好因为它把商业化变成了一个订阅模型。但对用户来说匿名账户需要“按月续费”会带来新的心理门槛如果哪个月忘记续费账户会怎样这又回到账户状态管理的复杂度。从现有公开信息看Signal 最终可能选择的是路径 A 或 B 的变体也可能直接在现有注册流程上增加一个“使用支付方式跳过手机号”的选项。具体方案要等官方发布。但不管选哪条路下面这些技术问题都是一定要解决的。4. 无手机号账户的技术流程与代码演示下面用几个模拟代码演示“无手机号付费注册”的账户体系设计。注意这些代码不是 Signal 官方实现而是为了帮助理解流程和关键设计点。4.1 注册流程状态机无手机号注册最核心的变化是流程变长从“填手机号 - 收验证码 - 创建账户”变成了“选择匿名注册 - 付费 - 生成密钥 - 展示恢复码 - 确认备份 - 创建身份”。后端可以用一个状态机来控制。# 文件路径demo/registration_flow.py # 演示代码模拟无手机号付费注册流程的状态机非 Signal 官方实现 class RegistrationState: START start PAYMENT_REQUIRED payment_required PAYMENT_VERIFYING payment_verifying KEY_GENERATION key_generation RECOVERY_SHOWN recovery_shown RECOVERY_CONFIRMED recovery_confirmed IDENTITY_CREATED identity_created class RegistrationFlow: def __init__(self): self.state RegistrationState.START def handle_event(self, event: str) - str: if self.state RegistrationState.START and event choose_anonymous: self.state RegistrationState.PAYMENT_REQUIRED elif self.state RegistrationState.PAYMENT_REQUIRED and event payment_received: self.state RegistrationState.PAYMENT_VERIFYING elif self.state RegistrationState.PAYMENT_VERIFYING and event payment_verified: self.state RegistrationState.KEY_GENERATION elif self.state RegistrationState.KEY_GENERATION and event keys_ready: self.state RegistrationState.RECOVERY_SHOWN elif self.state RegistrationState.RECOVERY_SHOWN and event recovery_backed_up: self.state RegistrationState.IDENTITY_CREATED else: raise ValueError(f非法状态迁移: {self.state} - {event}) return self.state关键点在于每一步状态迁移都必须有明确的触发器。用户付费后不是直接创建账户而是先进入支付验证再生成密钥和恢复码。这是因为无手机号账户没有“短信验证码”这个二次确认手段所有环节必须靠事件驱动否则很容易出现“钱付了账户没创建成功”的问题。4.2 恢复码生成与存储无手机号账户的生命线就是恢复码。恢复码需要满足三个条件高熵、便于抄写、服务端不可恢复明文。# 文件路径demo/recovery_code.py # 演示代码生成高强度恢复码并计算服务端存储哈希 import secrets import hashlib def generate_recovery_code() - str: # 32 字节随机数256 bit 熵暴力猜测成本极高 raw secrets.token_bytes(32) hex_code raw.hex().upper() # 每 8 位一组方便用户抄写和输入 grouped -.join(hex_code[i:i8] for i in range(0, len(hex_code), 8)) return grouped def hash_recovery_code(code: str) - str: # 服务端只保存 SHA-256 哈希不保存明文 # 实际生产环境建议使用带盐的慢哈希比如 scrypt/argon2 return hashlib.sha256(code.encode(utf-8)).hexdigest() if __name__ __main__: code generate_recovery_code() print(恢复码:, code) print(服务端存储:, hash_recovery_code(code))这段代码在真实项目中要注意两个问题。第一服务端存储建议用 argon2 或 scrypt 这种慢哈希而不是纯 SHA-256。第二恢复码展示给用户之后客户端要引导用户完成“确认抄写”步骤防止用户直接跳过备份。恢复码一旦丢失无手机号账户可能就永久失去访问能力这个 UX 设计必须谨慎。4.3 服务端防滥用校验去掉手机号后服务端在创建账户前需要增加支付凭证校验和速率限制。// 文件路径demo/AnonSignupService.java // 演示代码无手机号注册时的服务端防滥用校验非 Signal 官方实现 public class AnonSignupService { private final PaymentVerifier paymentVerifier; private final RateLimiter rateLimiter; private final IdentityStore identityStore; public AnonSignupService(PaymentVerifier paymentVerifier, RateLimiter rateLimiter, IdentityStore identityStore) { this.paymentVerifier paymentVerifier; this.rateLimiter rateLimiter; this.identityStore identityStore; } public SignupResult registerAnonymous(String paymentToken, String deviceFingerprint) { // 1. 同一个设备指纹在同一时间窗口内只能注册有限次数 if (!rateLimiter.tryAcquire(deviceFingerprint)) { return SignupResult.tooManyRequests(); } // 2. 校验支付凭证防止伪造支付回调 if (!paymentVerifier.verify(paymentToken)) { return SignupResult.paymentRejected(); } // 3. 创建匿名身份不绑定手机号 AnonymousIdentity identity identityStore.createAnonymousIdentity(); // 4. 生成一次性恢复码返回给客户端 String recoveryCode identity.generateRecoveryCode(); return SignupResult.success(identity.getId(), recoveryCode); } }这里的关键设计是“把支付也当成反滥用的一环”。但要注意支付凭证验证必须在服务端做不能只依赖客户端传来的支付结果。生产环境还要处理支付回调的幂等性遇到重复回调不能重复创建账户。5. 去掉手机号之后账户安全工作流会发生什么无手机号注册表面上只是把“填手机号”这一步骤改成了“付费”但整个账户安全体系都会因此产生连锁反应。下面按安全工作流逐层拆解。5.1 身份恢复从“验证码找回”变成“恢复码找回”原先用户换手机只需要短信验证码就能找回账户。这个流程对用户很友好安全强度取决于 SIM 卡是否被保护。无手机号账户没有短信通道找回只能靠恢复码或者提供额外的备用邮箱、备用设备授权。这意味着产品团队必须做两件事一是把恢复码的备份流程做到极致二是提供可选的备用联系方式。否则“没有手机号”的状态很容易变成“账户无法找回”的隐患。5.2 信任模型从“号码即身份”变成“公钥即身份”在 Signal 原有的模型里手机号是公开可见的身份标识两个人的信任关系可以建立在号码匹配上。去掉手机号后账号信息里可能只剩一个随机 ID 和公钥指纹。这对隐私更友好但用户之间如何验证“对方确实是那个人”会更难安全码校验的展示方式也要重新设计。5.3 反滥用从“SIM 卡成本”变成“支付成本 设备指纹 行为检测”手机号天然有注册成本去掉手机号后开发者需要叠加多层策略设备指纹识别同一台设备是否尝试重复注册。支付风控识别礼品卡、盗刷、代充的黑产链。行为特征分析注册后的使用行为比如是否在短时间内大量发消息。邀请限制限制无手机号账户的邀请能力防止灰产批量扩散。这些策略单独看都不完美组合起来才能形成有效的阻尼。从现有信息看Signal 如果真的上线付费免手机号注册大概率会把这几种手段一起用上。5.4 合规与审计需要重新定义“用户标识”很多地区对即时通讯软件有实名或备案要求留存“手机号”也是平台审计的重要手段。无手机号账户上线后运营团队必须重新定义“用户标识”当用户申诉、账号被盗、配合执法调查时唯一标识是什么如果只有一个随机 ID平台如何定位到具体账户这不仅是产品决策也是法务和合规决策。6. 对开发者的启示如何设计不依赖手机号的账户体系Signal 这次尝试的最大价值不是某个功能本身而是给所有做账户体系的团队提供了一个现实案例手机号并不是唯一可选的身份源。下面这些设计思路在任何需要“降级手机号依赖”的产品里都适用。6.1 把“身份”和“认证方式”分离很多产品的账户体系把手机号既当作“身份标识”又当作“登录凭证”和“找回凭证”。这是最省事的设计但一旦要支持无手机号用户就会陷入重复绑定、账号合并、找回困难等问题。更稳妥的做法是系统内部使用自增 ID 或 UUID 作为主身份标识手机号只是其中一个登录因子。这样未来想加“邮箱登录”“硬件密钥登录”“无手机号注册”时只需要新增一种认证因子不需要重构用户表。6.2 恢复码要设计成“多备份可验证”凡是涉及敏感资产的账户都应该在注册时给用户提供恢复码并引导用户至少保存两份比如一份抄写在纸上、一份放密码管理器。产品还要提供“恢复码验证”的测试流程让用户确认自己保存的恢复码确实有效而不是等到账户丢了才发现抄错了。6.3 风控要分层不能依赖单一门槛如果你在做一个匿名或弱实名产品付费门槛可以降低垃圾注册但不要指望它解决所有问题。更成熟的方案是把注册成本分成多层新账户创建后的前 N 天限制部分操作设备指纹异常时提高验证要求出现群发、短时大量添加好友等行为时直接进入人工审核。6.4 灰度发布时要设计“退出路径”去手机号化是对已有用户习惯的破坏性改动。即使 Signal 上线了免手机号注册也可以先把新用户放进单独的注册通道里观察找回率、滥用率、付费转化率再决定是否向全量开放。对开发者来说任何账户体系的重大变更都要考虑现有用户能不能平滑过渡新用户是不是真的比旧用户多如果数据不理想怎么回滚到保持手机号方案7. 常见问题与排查思路Signal 官方尚未公开无手机号注册的详细支持文档以下问题来自各类账户体系的共性问题可用来建立排查思路。问题现象可能原因排查方式解决方案注册后一直提示“验证处理中pending”风控进入人工审核或二次验证未完成检查注册邮箱/短信的验证链接查看账户状态页按指引完成二次验证长时间未响应再联系支持渠道登录时提示 access denied账户被风控标记、设备环境异常、多次验证失败核对网络环境和设备指纹检查恢复码输入是否正确更换可信网络重试必要时提交账户申诉账户被锁定account locked短时间内多次输错验证码安全策略自动锁定查看账户状态页的锁定倒计时检查是否有解锁邮件等待自动解锁走身份恢复流程恢复码丢失注册时未备份或备份介质损坏检查是否绑定过备用邮箱/备用设备用备用方式找回若完全没有绑定只能重建账户付费成功但账户未创建支付回调延迟、幂等逻辑缺陷、客户端未刷新状态查询支付订单状态服务端检查支付回调日志手动补发账户创建请求修复幂等逻辑当用户遇到这些问题时最有效的排查路径是先看是“注册阶段”还是“登录阶段”的问题再看是“身份验证失败”还是“风控拦截”然后针对性查看日志。不要一股脑让用户重装应用。8. 趋势判断从“手机号即身份”到“可分离账户身份”Signal 的付费免手机号注册实验放在更长的时间轴上看并不是孤例。近几年整个行业都在尝试降低对手机号的依赖Apple 的“隐藏邮件地址”功能让用户可以用随机邮箱接收邮件把真实邮箱和 App 隔离开。Passkey 正在推动人们用设备生物识别代替密码和验证码登录因子变成“设备上的一把私钥”而不是“你拥有的一个号码”。很多开发者也在把账户系统从“手机号 验证码”往“邮箱 密码 多因素认证”迁移虽然