核心结论
无手机号注册解决的是身份暴露问题，却会立刻把垃圾注册、账号找回和联系人发现推到系统设计的前台。一个可用方案不该把手机号简单换成用户名，而要把“用户能证明自己具备注册资格”与“服务端知道用户是谁”拆开。
隐私与反滥用的矛盾
手机号在即时通信产品里常被同时拿来做登录凭证、找回通道、通讯录匹配键和反滥用门槛。它方便，却留下两个长期成本。用户换号、跨地区使用或不愿交出实名号码时会被挡在门外。更麻烦的是，号码天然是强关联标识，泄露、撞库或通讯录上传都可能扩大可关联范围。
零知识证明适合处理其中一部分矛盾。注册系统可以给合格用户发放一个不可伪造的凭证，后续登录时，客户端只证明自己持有有效凭证，不提交原始号码、付款信息或完整身份。服务端验证证明后创建账号公钥和恢复材料。证明系统仍会暴露必要的业务信号，例如一次注册是否已经使用、凭证是否过期、风控是否拒绝请求。隐私目标应写清这些边界，不能把“无手机号”宣传成完全匿名。
凭证和账号如何拆分
工程上首先要分开三类标识。账号内部应使用随机、不可枚举的主体 ID。对外可见名称应允许更换，并且不能直接充当授权凭证。联系人发现应改为用户主动共享的标识或受保护的匹配协议，避免把整个通讯录变成服务端索引。只做到第一步，仍可能在同步、邀请和恢复流程里把手机号重新带回来。
反滥用是难点。手机号的稀缺性原本提供了一点成本，移除后必须另建成本。可组合的办法包括限速、设备或客户端完整性信号、支付或邀请码凭证、注册冷却期，以及按行为逐步提升权限。每一种手段都有误伤风险。把设备指纹当成唯一门槛会伤害换机用户，也可能形成新的长期跟踪标识。把付款当成唯一门槛会排除没有合适支付方式的人。
实现步骤与恢复边界
账号恢复需要在注册时确定。只靠密码通常不足以应对设备丢失，只靠邮箱又把风险转移到邮箱。较稳妥的路径是支持多设备批准、恢复密钥或受限的恢复联系人，并让用户知道每种方式能恢复什么。恢复操作必须有等待期、通知和可撤销窗口，因为攻击者最愿意打的就是恢复入口。
上线前可按四个问题验收。服务端日志里是否还保存原始号码或可逆映射。联系人发现是否能批量枚举。单个凭证能否无限创建账户。失去全部设备的用户能否在不泄露额外身份材料的情况下恢复。任何一项没有答案，功能都还停在概念阶段。
FAQ
无手机号是否等于匿名。不是。网络地址、付款、设备和使用行为都可能形成关联信号，系统只能减少不必要的中心化标识收集。
小团队能否直接上零知识证明。可以先从随机账号 ID、最小化日志和严格限速做起。证明协议应使用经审计实现，并把性能、凭证撤销和异常恢复纳入测试。