# 设备静默登录机制设计方案 ## 需求分析 1. 用户进来之后就是静默登录(设备登录) 2. 用户可以主动关联邮箱;也可以不关联邮箱 3. 用户换手机后在别的地方用邮箱登录会绑定另外一部手机的设备号 4. 没有游客概念,快捷登录进来的用户就是正式用户 ## 当前系统分析 ### 现有认证流程 - **设备登录**:已存在 `deviceLoginLogic.go`,通过设备标识符自动登录 - **邮箱登录**:已存在 `userLoginLogic.go`,需要邮箱+密码 - **游客模式**:通过 `Order.UserId = 0` 标识游客订单 ### 现有设备管理 - **设备绑定**:`bindDeviceLogic.go` 处理设备与用户绑定 - **设备解绑**:`unbindDeviceLogic.go` 处理设备解绑 - **设备迁移**:支持设备在用户间转移 ## 设计方案 ### 1. 核心改动策略 - **保留现有设备登录机制**,作为默认登录方式 - **移除游客概念**,所有设备登录用户都是正式用户 - **增强邮箱绑定功能**,支持跨设备登录 - **优化设备迁移逻辑**,支持邮箱登录后绑定新设备 ### 2. 具体实现方案 #### 2.1 修改设备登录逻辑 **文件**: `internal/logic/auth/deviceLoginLogic.go` **改动点**: - 移除 `registerUserAndDevice` 中的试用激活逻辑 - 确保所有通过设备登录创建的用户都是正式用户 - 保持现有的设备绑定机制 #### 2.2 修改订单处理逻辑 **文件**: `queue/logic/order/activateOrderLogic.go` **改动点**: - 移除 `getUserOrCreate` 中的游客判断逻辑 (`orderInfo.UserId == 0`) - 移除 `createGuestUser` 函数 - 修改为:如果订单没有关联用户,通过设备标识符创建或获取用户 #### 2.3 修改订单关闭逻辑 **文件**: `internal/logic/public/order/closeOrderLogic.go` **改动点**: - 移除对 `UserId == 0` 的特殊处理 - 统一处理所有订单的关闭逻辑 #### 2.4 增强邮箱登录逻辑 **文件**: `internal/logic/auth/userLoginLogic.go` **改动点**: - 在邮箱登录成功后,如果提供了设备标识符,自动绑定设备 - 支持邮箱登录后在新设备上的自动绑定 #### 2.5 优化设备绑定逻辑 **文件**: `internal/logic/auth/bindDeviceLogic.go` **改动点**: - 增强设备迁移逻辑,支持邮箱用户登录新设备时的自动绑定 - 保持现有的设备冲突处理机制 ### 3. 数据库变更 **无需修改数据库结构**,现有的用户和设备表结构已经支持新的需求。 ### 4. API 变更 **无需修改 API 接口**,现有的设备登录和邮箱登录接口已经满足需求。 ### 5. 前端适配 **前端需要调整**: - 默认使用设备登录作为主要登录方式 - 提供邮箱绑定入口 - 在新设备上提供邮箱登录选项 ## 实施步骤 ### 第一步:修改订单逻辑 1. 修改 `activateOrderLogic.go`,移除游客概念 2. 修改 `closeOrderLogic.go`,统一订单处理逻辑 ### 第二步:增强设备登录 1. 确保设备登录创建的都是正式用户 2. 优化设备绑定逻辑 ### 第三步:增强邮箱登录 1. 在邮箱登录后支持设备绑定 2. 优化跨设备登录体验 ### 第四步:测试验证 1. 测试设备静默登录 2. 测试邮箱绑定功能 3. 测试跨设备登录 ## 优势分析 ### 1. 最小化改动 - 复用现有的设备登录机制 - 保持现有的数据库结构 - 保持现有的 API 接口 ### 2. 用户体验提升 - 用户进入即可使用,无需注册 - 支持邮箱绑定,便于跨设备使用 - 保持数据连续性 ### 3. 系统稳定性 - 基于现有成熟机制 - 减少新增代码量 - 降低引入 bug 的风险 ## 风险评估 ### 1. 数据迁移 - **风险**: 现有游客数据需要处理 - **方案**: 可以保持现有游客数据不变,新用户使用新机制 ### 2. 兼容性 - **风险**: 现有客户端可能需要适配 - **方案**: 保持 API 兼容,逐步引导用户使用新机制 ### 3. 性能影响 - **风险**: 设备登录可能增加数据库压力 - **方案**: 现有机制已经过验证,影响可控