hi-server/DESIGN_SILENT_LOGIN.md

设备静默登录机制设计方案

需求分析

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. 性能影响

• 风险: 设备登录可能增加数据库压力
• 方案: 现有机制已经过验证，影响可控