注销账号（零售端）#

验证状态：已源码核验、未联调（无 app 调用图）；services 基线：源码归纳 @ 2026-09-14

用途与场景#

注销当前登录账号（零售 App 专属端点，/v1/retail 新代用户中心唯一端点）：免验证码、免频控，调用即向服务端发布 USER_DEACTIVATE JMS 消息，由监听器异步删除该用户的个人空间数据。App 在「设置 → 账号注销」入口调用本端点；因无二次验证，App 侧应自行做强确认交互（二次确认弹层、输入文案等）再发起。

App 现役依据#

判定证据	内容
旧 app 文档收录记录	无收录——旧 app 文档仓与本仓旧 retail 手册（git 历史，仅 list/share 两页）都没有本端点；现役判定由后两行承担
两代分工语义	/v1/retail 门面为零售新客户端而建，本端点是其用户中心唯一端点；验证码变体 deactivateWithVerification 属第一代 user Plus（Web 链路，机构手册正本），零售 App 的注销通道只有本端点
后端持续维护迹象	注销消息的消费与发布链路 2026-08-27 仍有重构提交（通道契约收敛），注销链路属活跃维护面

端点#

POST /main-service/system-api/v1/retail/user-center/user/deactivate — 零售 App 账号注销（免验证码，异步受理）。

端点全量事实（参数、请求/响应字段、错误码、权限点）见清单层 user-center · v1-retail 零售接口（v1）；注销语义（受理与异步删除、与验证码变体的安全差异对照、删除范围明细）见用户中心业务 · v1-retail 零售接口（v1）。

动线与完成判据#

status=200 且 data=true 表示注销请求已受理（JMS 已发布）。数据删除为异步：受理成功后个人空间数据、绑定关系与账户本身何时对查询不可见取决于消费时序，App 不应假设同步完成；受理后应清除本地凭据并退出登录流程，后续请求会以已注销用户失败。

错误与边界#

无业务拒绝分支：受理路径没有任何校验失败出口（注销对象取自认证上下文，空白场景由认证层先拦截）。失败出口只有认证族（HTTP 200 + status=1000，未登录/凭据失效）与协议/服务器错误族，判定口径见错误响应差异。安全边界提示：任何持有该用户有效 token 的一方（含 token 泄露场景）都能直接发起不可逆注销；对注销后果敏感的场景应评估改走验证码变体（Web 链路，对照见用户中心业务 · v1-retail 零售接口（v1））。重复调用：注销受理后账户数据被软删，再次调用仍返回成功（无存在性校验），App 侧应在首次成功后即终结注销流程。

调用关系与资源清理#

App 侧清理：注销受理成功后应立即清除本地 token、用户资料与 MQTT 会话（服务端已删除该用户 MQTT 关联数据面并清登录租户缓存）；此后持有旧 token 的请求行为未由源码闭合（认证缓存已清，预期认证失败）。服务端残留：filesStoragePath 下经按文件号上传落盘的文件目录不在监听器删除范围内（监听器只删数据行与缓存），文件残留行为未由源码闭合。

已知缺口#

未执行真实联调：JMS 消费延迟与失败重试语义、注销后旧 token 的实际失效时序、多设备在线时其他设备的踢出行为均无 App 实测佐证。异步删除的最终一致性窗口（受理成功到数据不可见）无 SLA 证据。