接到注销需求,先问两个问题
接到注销需求,先问两个问题
用户注销账号——这个功能听起来不复杂,无非就是删掉数据。
但在动手之前,两个问题必须先问清楚:数据删到什么程度? 注销后用同一手机号重新注册,老数据要不要继承?
这两个问题的答案,决定了整个方案的走向。
软删除,而不是物理删除
直接 DELETE FROM user WHERE id = ? 是最危险的做法。
原因一:历史订单、交易记录、日志需要保留(法律合规、对账、客诉追溯)。
原因二:物理删除后,这个账号 ID 可能被新账号复用,历史数据的 user_id 就指向了错误的人。
原因三:误操作无法恢复。
标准做法是软删除:在 user 表加 deleted_at 和 deleted 字段,注销时打标而不是删行:
UPDATE user
SET deleted = 1,
deleted_at = NOW(),
phone = CONCAT('deleted_', id, '_', phone), -- 手机号脱敏,腾出号码供重新注册
nickname = '已注销用户'
WHERE id = ?
手机号脱敏这一步很关键:如果不腾出来,这个号码永远被占着,用户换手机号后无法重新注册;腾出来了,但要保留"这个号曾经注册过"的痕迹,以便后续处理。
注销后重新注册:老数据怎么处理
这是最容易踩坑的地方。
用户注销了账号 A(手机号 138xxxx),过了半年用同一个手机号重新注册,系统创建了账号 B。
账号 B 应该看到账号 A 的历史数据吗?
通常答案是:不应该。注销意味着数据清算,新号就是新用户。如果把账号 A 的历史数据自动继承给账号 B,会带来:
- 账号 A 的敏感信息(收货地址、消费记录)泄露给了同号码的新用户
- 账号 A 的黑名单、违规记录也被继承,新用户莫名其妙
所以软删除时,user_id 不复用,账号 B 是全新的 ID,看不到账号 A 的任何数据。
注销流程的必要步骤
注销不只是打一个删除标记,要触发一系列清理:
| 步骤 | 内容 | 时机 |
|---|---|---|
| 解绑第三方 | 解除微信/支付宝/Apple 绑定 | 注销时同步 |
| 取消订阅 | 退出所有会员/自动续费 | 注销时同步 |
| 冻结余额 | 账户余额/积分处理(退款或作废) | 注销时触发 |
| 数据脱敏 | 手机号、姓名、身份证等打码 | 可异步,7 天内完成 |
| 清除登录态 | 所有设备 Token 失效 | 注销时同步 |
| 保留合规数据 | 交易记录、日志按法规期限保留 | 永久(或按规定期限) |
有些步骤失败了怎么办(比如解绑第三方接口超时)?注销流程要设计成可补偿的,记录每个步骤的状态,失败的异步重试,不要因为一个步骤失败让整个注销流程回滚——用户在注销页面等着,超时会很崩溃。
冷静期和二次确认
注销是不可逆操作,主流平台都设 7-15 天冷静期:
- 提交注销申请 → 状态变为"注销申请中"
- 冷静期内用户可以撤销
- 冷静期结束 → 正式执行注销流程
冷静期的副作用:这段时间手机号还不能被释放,用户如果换号要等冷静期过完。提前在 UI 上说清楚,减少客诉。
评论(0)
登录后参与评论。
还没有评论,来抢沙发吧。

