shanshanzhong
3bbd687231
All checks were successful
Build docker and publish / build (20.15.1) (push) Successful in 6m41s
在设备重新绑定到新用户时，自动迁移旧用户的订单、订阅和余额数据 移除游客订单特殊处理逻辑，统一所有订单处理流程 更新设备绑定文档说明新的静默登录机制
128 lines
4.0 KiB
Markdown
128 lines
4.0 KiB
Markdown
# 设备静默登录机制设计方案
|
||
|
||
## 需求分析
|
||
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. 性能影响
|
||
- **风险**: 设备登录可能增加数据库压力
|
||
- **方案**: 现有机制已经过验证，影响可控 |