账号注销需同步清理token、缓存、服务注册及业务数据：token黑名单须持久化并前置校验；关联缓存需主动失效；服务注册须显式注销；业务数据应异步分步清理并留回滚窗口；跨系统需事件广播通知。
账号注销不是删掉用户记录就完事，必须同步清理 token、关联缓存、服务注册状态和业务数据，否则会留下安全与一致性隐患。
token 黑名单必须持久化且可快速校验
单纯把 sysUser.Token 写进内存 map 或本地文件，重启服务后就失效。生产环境应写入 Redis 或数据库，并在鉴权中间件中前置校验：blacklist.Exists(token)。注意两点：一是 token 过期时间要和黑名单 TTL 对齐（比如 token 2 小时过期，黑名单至少保留 2 小时）；二是避免用 SELECT * FROM blacklist WHERE token = ? 全表扫，必须给 token 字段建唯一索引或使用 Redis 的 SET 结构。
关联缓存需按业务维度主动失效，不能等自然过期
用户退出后，其个人配置、权限树、未读消息数等缓存若还留着，下次同名用户登录可能拿到旧数据。不要依赖缓存自动淘汰——它可能几小时都不触发。应在 Logout 函数里显式调用：cache.Delete("user_profile:" + sysUser.Uuid)、cache.Delete("user_perms:" + sysUser.Uuid)。若用的是带前缀的批量删除（如 Redis 的 KEYS user_*_123），务必确认命令在生产环境允许（有些集群禁用 KEYS），改用 SCAN + DEL 组合更稳妥。
服务注册状态要显式注销，避免僵尸实例
如果该账号对应一个微服务实例（比如 IoT 设备绑定后台服务），仅删数据库记录，Consul/Etcd 里仍显示 “healthy”。必须在注销流程中调用：consulClient.Agent().ServiceDeregister(serviceID)，且需包裹 recover() 防止网络失败 panic 导致整个注销流程中断。同时检查本地是否缓存了该服务的 serviceID，避免重复调用 Deregister 报错。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
业务数据清理要分步、可逆、带日志
真正删库操作（如清空用户上传的附件表、聊天记录）不能放在 HTTP 请求链路里同步执行——耗时长、易超时、失败难回滚。应转为异步任务：task.Enqueue("cleanup_user_data", map[string]interface{}{"user_id": sysUser.ID})。任务队列中再分阶段处理：先标记为“待清理”，再逐批删除，每批完成后写入 cleanup_log 表记录进度。关键点是：不直接 DELETE FROM，而是先 UPDATE SET status = 'deleted'，后续定时 job 才物理删除，留出人工干预窗口。
最常被跳过的环节是跨系统通知——比如用户在 A 系统注销，B 系统的单点登录 session 还活着。这类清理没法靠单点逻辑兜住，得靠统一认证中心或事件总线广播 user.logout 事件，各订阅方自行响应。
