接到注销需求，先问两个问题

用户注销账号——这个功能听起来不复杂，无非就是删掉数据。

但在动手之前，两个问题必须先问清楚：数据删到什么程度？ 注销后用同一手机号重新注册，老数据要不要继承？

这两个问题的答案，决定了整个方案的走向。

软删除，而不是物理删除

直接 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 的任何数据。

注销流程的必要步骤

注销不只是打一个删除标记，要触发一系列清理：

有些步骤失败了怎么办（比如解绑第三方接口超时）？注销流程要设计成可补偿的，记录每个步骤的状态，失败的异步重试，不要因为一个步骤失败让整个注销流程回滚——用户在注销页面等着，超时会很崩溃。

冷静期和二次确认

注销是不可逆操作，主流平台都设 7-15 天冷静期：

• 提交注销申请 → 状态变为"注销申请中"
• 冷静期内用户可以撤销
• 冷静期结束 → 正式执行注销流程

冷静期的副作用：这段时间手机号还不能被释放，用户如果换号要等冷静期过完。提前在 UI 上说清楚，减少客诉。