---
title: 账户删除
description: 用户在 with.sudomimus.com 删除账户后，应用会看到什么、Sudomimus 会清除哪些服务端数据，以及如何处理相应的错误符号。
editUrl: true
head: []
template: doc
sidebar:
  order: 7
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

Sudomimus 用户可以随时通过 [`with.sudomimus.com`](https://with.sudomimus.com) 的个人资料页面永久删除账户。本页面向**已经集成 Sudomimus 的应用开发者**，说明账户删除后应用会看到什么，以及应当如何处理。

面向用户的流程本身——包括确认步骤与政策文本——属于 [隐私政策](https://sudomimus.com/legal-hub/privacy) 的一部分。

## 应用会看到什么

在准入和刷新阶段，已删除账户的处理方式与停用账户类似。两者使用不同的错误符号，而且删除状态**不可逆**。

| 调用时机 | 收到的错误 | HTTP / OIDC 映射 |
|---|---|---|
| Connect `POST /redeem` | `AccountDeleted` | `403 Forbidden` |
| Connect `POST /refresh` | `AccountDeleted` | `403 Forbidden` |
| Native API `POST /direct-issue/steam-ticket` | `AccountDeleted` | `403 Forbidden` |
| Native API `POST /direct-issue/access-key` | `AccountDeleted` | `403 Forbidden` |
| OIDC API `POST /token`（auth-code） | `invalid_grant` — "Account is deleted" | `400` |
| OIDC API `POST /token`（refresh-token） | `invalid_grant` — "Account is deleted" | `400` |
| OIDC API `GET /userinfo` | `invalid_token` — "Account is deleted" | `401` |

`AccountDeleted` 与现有的 `AccountDisabled` 相对应。**已经签发的访问令牌不会被追溯撤销**，而是继续有效到各自的 `exp`，与账户停用的行为一致。应用通常会在下一次刷新时发现账户已删除，而不是在用户点击删除按钮的那一刻。

## 如何处理 `AccountDeleted`

处理方式与 `AccountDisabled` 基本相同，但有一处重要区别：不要显示「账户已暂停，请联系支持」之类的提示。账户删除是用户主动执行的操作，应用应清除本地会话，并在用户需要时引导其重新注册。

简单的决策树：

```
/refresh 收到 AccountDeleted
  │
  ▼
清除本地 access cookie / SDK 状态
  │
  ▼
显示已登出页面
  │
  ▼
（可选）提供"重新注册"按钮 → 进入新的 /establish 流程
```

应用**不应**执行以下操作：

- 不要重试——该符号是终态，不是瞬态错误。
- 不要替用户自动重建账户。重新注册必须是用户的主动行为。
- 不要假设用户此前的数据可以延续。即使使用同一邮箱重新注册，应用看到的也是全新的 `subject`（扇区主体，sector subject），与旧账户没有历史关联。

## 独自拥有仍在运行的组织会阻塞删除

应用（Application）与扇区（Sector）归 **组织（Organization）** 所有，而非归个人所有，因此删除是在组织这一层把关的：只要用户是**某个仍持有存活资源的组织的唯一 `OWNER`**，就无法删除账户。

- 当你是某个组织的**唯一 `OWNER`**，且它仍持有任一**已启用**的应用或**尚未停用**的扇区时，该组织会阻塞删除。下线这些资源即可解除阻塞。
- **共同拥有**的组织从不阻塞——还有另一位 `OWNER` 可以管理它。
- 资源已全部停用的组织从不阻塞；删除时它会直接变为无主状态。

删除尝试会以 `AccountOwnsLiveOrganizations` 失败（映射为 HTTP `409 Conflict`）；响应会带上阻塞的组织的 anchor，供产品内流程精确列出需要下线的对象。

因此，通往删除的完整路径是一条「先下线、后删除」的级联：在每一个你独自拥有的组织中，先停用每个应用，再停用此时已清空的每个扇区（此时已被允许，因为它们的应用都已停用），最后才删除账户。（你也可以顺带停用该组织本身，但这对删除并非必需。）

这是有意为之。组织——以及它所拥有的应用与扇区——是承载着其他人数据的基础设施，因此 Sudomimus 不会作为某位开发者删除个人账户的副作用而静默销毁它。如果你独自拥有一个仍有存活资源的组织并计划关闭账户，请先为它安排一个下线步骤。

## 重新注册的语义

删除账户后再次注册——即便使用同一邮箱——所得到的是一个**全新账户**，与已删除的账户没有任何历史关联：

- 一个全新的内部账户，因此会在每个应用扇区下获得新的 `subject`（扇区主体），应用收到的值也会改变。
- 新的 `EmailIdentity` 行（旧行已被删除，该邮箱已被释放）。
- 新的 `Authentication` 行。
- 偏好、应用、会话——无任何延续。

从应用视角看，这与全新用户没有区别。以 `subject` 为主键的本地数据存储应将新旧账户视为互不相关。

## 相关

- [管理会话](/zh-cn/guides/managing-sessions/) — 不删除账户的情况下结束会话所用的 `/logout` 与 `/revoke-all`。
- [隐私政策 — 删除你的账户](https://sudomimus.com/legal-hub/privacy) — 同一规则面向用户的说明。