292 lines
6.6 KiB
Markdown
292 lines
6.6 KiB
Markdown
# 多身份功能实现评估
|
||
|
||
> 评估时间：2026-02-26
|
||
> 评估内容：一个账号支持多个身份的实现难度和风险
|
||
|
||
---
|
||
|
||
## 📊 实现难度评估
|
||
|
||
### 难度等级：⭐⭐⭐⭐ (中高难度)
|
||
|
||
### 需要修改的模块
|
||
|
||
#### 1. 数据库层 (难度：⭐⭐)
|
||
**修改内容：**
|
||
- 创建 `user_roles` 关联表
|
||
- 保留 `user.user_type` 作为默认身份
|
||
- 添加多身份关联关系
|
||
|
||
**工作量：** 1-2小时
|
||
- 编写SQL脚本
|
||
- 数据迁移（现有用户数据）
|
||
- 测试数据完整性
|
||
|
||
#### 2. 后端代码 (难度：⭐⭐⭐⭐)
|
||
**修改内容：**
|
||
- 修改 `User` 实体类（添加 roles 列表）
|
||
- 创建 `UserRole` 实体和 Mapper
|
||
- 修改登录逻辑（返回所有角色）
|
||
- 添加角色切换接口
|
||
- 修改权限验证逻辑（支持多角色）
|
||
- 修改所有依赖 `user.role` 的业务逻辑
|
||
|
||
**影响范围：**
|
||
- `UserService` - 登录、注册、用户信息
|
||
- `AuthController` - 认证相关接口
|
||
- 所有使用 `user.getRole()` 的地方（约50+处）
|
||
- 权限拦截器/过滤器
|
||
|
||
**工作量：** 2-3天
|
||
|
||
#### 3. 前端代码 (难度：⭐⭐⭐)
|
||
**修改内容：**
|
||
- 修改 `store/user.js`（支持多角色）
|
||
- 修改登录逻辑（接收多角色）
|
||
- 修改角色切换逻辑（调用后端API）
|
||
- 修改所有角色判断的地方
|
||
- 添加角色选择器组件
|
||
|
||
**影响范围：**
|
||
- 所有使用 `userStore.currentRole` 的页面（约30+个文件）
|
||
- 所有角色判断逻辑（`isTeacher`, `isManager` 等）
|
||
|
||
**工作量：** 1-2天
|
||
|
||
---
|
||
|
||
## ⚠️ 风险评估
|
||
|
||
### 高风险项 🔴
|
||
|
||
#### 1. 数据一致性风险
|
||
**风险描述：**
|
||
- 现有用户数据迁移可能出错
|
||
- 多身份关联关系可能不一致
|
||
|
||
**影响：**
|
||
- 用户无法登录
|
||
- 身份显示错误
|
||
- 权限混乱
|
||
|
||
**缓解措施：**
|
||
- 充分测试数据迁移脚本
|
||
- 保留原有 `user_type` 字段作为备份
|
||
- 提供数据回滚方案
|
||
|
||
#### 2. 业务逻辑风险
|
||
**风险描述：**
|
||
- 大量代码依赖单一角色逻辑
|
||
- 修改可能引入新bug
|
||
- 权限验证可能出现漏洞
|
||
|
||
**影响：**
|
||
- 功能异常
|
||
- 数据错乱
|
||
- 安全问题
|
||
|
||
**缓解措施：**
|
||
- 全面的代码审查
|
||
- 完整的测试用例
|
||
- 分阶段上线
|
||
|
||
#### 3. 前后端联调风险
|
||
**风险描述：**
|
||
- 接口变更可能导致前后端不兼容
|
||
- 角色切换逻辑复杂
|
||
|
||
**影响：**
|
||
- 页面报错
|
||
- 功能不可用
|
||
|
||
**缓解措施：**
|
||
- 详细的接口文档
|
||
- 充分的联调测试
|
||
|
||
### 中风险项 🟡
|
||
|
||
#### 4. 性能风险
|
||
**风险描述：**
|
||
- 多表关联查询可能影响性能
|
||
- 每次请求都需要查询角色
|
||
|
||
**影响：**
|
||
- 响应变慢
|
||
- 数据库压力增大
|
||
|
||
**缓解措施：**
|
||
- 使用缓存（Redis）
|
||
- 优化SQL查询
|
||
- 添加索引
|
||
|
||
#### 5. 用户体验风险
|
||
**风险描述：**
|
||
- 角色切换逻辑可能让用户困惑
|
||
- 多身份管理复杂
|
||
|
||
**影响：**
|
||
- 用户投诉
|
||
- 使用困难
|
||
|
||
**缓解措施：**
|
||
- 清晰的UI设计
|
||
- 用户引导
|
||
- 帮助文档
|
||
|
||
---
|
||
|
||
## 💰 成本收益分析
|
||
|
||
### 实施成本
|
||
| 项目 | 时间 | 风险 |
|
||
|------|------|------|
|
||
| 数据库设计 | 0.5天 | 低 |
|
||
| 数据迁移 | 0.5天 | 高 |
|
||
| 后端开发 | 2-3天 | 高 |
|
||
| 前端开发 | 1-2天 | 中 |
|
||
| 测试 | 2-3天 | 高 |
|
||
| 上线部署 | 0.5天 | 中 |
|
||
| **总计** | **7-10天** | **高** |
|
||
|
||
### 业务价值
|
||
- ✅ 用户可以同时拥有多个身份（如：既是家长又是陪伴员）
|
||
- ✅ 减少账号数量，方便管理
|
||
- ✅ 提升用户体验
|
||
- ❌ 增加系统复杂度
|
||
- ❌ 维护成本增加
|
||
|
||
---
|
||
|
||
## 🎯 建议方案
|
||
|
||
### 方案A：完整实现多身份 (不推荐)
|
||
**适用场景：** 业务强需求，必须支持多身份
|
||
|
||
**优点：**
|
||
- 功能完整
|
||
- 用户体验好
|
||
|
||
**缺点：**
|
||
- 开发周期长（7-10天）
|
||
- 风险高
|
||
- 测试工作量大
|
||
- 可能影响现有功能
|
||
|
||
**建议：** ❌ 不推荐，除非有明确的业务需求
|
||
|
||
---
|
||
|
||
### 方案B：保持现状 + 优化切换体验 (推荐)
|
||
**适用场景：** 当前单身份设计已满足业务需求
|
||
|
||
**实施内容：**
|
||
1. 保持数据库单身份设计
|
||
2. 优化前端角色切换UI
|
||
3. 添加"申请其他身份"功能（创建新账号）
|
||
4. 提供账号关联功能（同一手机号多个账号）
|
||
|
||
**优点：**
|
||
- 风险低
|
||
- 开发快（1-2天）
|
||
- 不影响现有功能
|
||
- 满足大部分场景
|
||
|
||
**缺点：**
|
||
- 需要多个账号
|
||
- 切换需要重新登录
|
||
|
||
**建议：** ✅ 推荐，性价比高
|
||
|
||
---
|
||
|
||
### 方案C：分阶段实现 (折中方案)
|
||
**适用场景：** 未来可能需要多身份，但不急
|
||
|
||
**阶段1：** 数据库设计预留（1天）
|
||
- 创建 `user_roles` 表
|
||
- 保持现有逻辑不变
|
||
- 为未来扩展做准备
|
||
|
||
**阶段2：** 后端支持多身份（2-3天）
|
||
- 修改后端逻辑
|
||
- 保持前端不变
|
||
- 充分测试
|
||
|
||
**阶段3：** 前端支持多身份（1-2天）
|
||
- 修改前端逻辑
|
||
- 完整联调测试
|
||
|
||
**优点：**
|
||
- 风险可控
|
||
- 可以随时停止
|
||
- 逐步验证
|
||
|
||
**缺点：**
|
||
- 总时间更长
|
||
- 需要多次上线
|
||
|
||
**建议：** 🟡 可选，适合有长期规划的情况
|
||
|
||
---
|
||
|
||
## 📋 决策建议
|
||
|
||
### 如果你的业务场景是：
|
||
|
||
#### 1. 用户很少需要多个身份
|
||
**建议：** 方案B（保持现状）
|
||
- 大部分用户只有一个身份
|
||
- 少数需要多身份的用户可以注册多个账号
|
||
- 提供账号关联功能即可
|
||
|
||
#### 2. 很多用户需要多个身份
|
||
**建议：** 方案C（分阶段实现）
|
||
- 先做数据库设计
|
||
- 逐步实现功能
|
||
- 降低风险
|
||
|
||
#### 3. 必须立即支持多身份
|
||
**建议：** 方案A（完整实现）
|
||
- 做好充分的测试
|
||
- 准备回滚方案
|
||
- 预留足够的开发时间
|
||
|
||
---
|
||
|
||
## 🎯 我的建议
|
||
|
||
**推荐方案B：保持现状 + 优化体验**
|
||
|
||
**理由：**
|
||
1. **风险低** - 不影响现有功能
|
||
2. **开发快** - 1-2天即可完成
|
||
3. **够用** - 满足大部分业务场景
|
||
4. **可扩展** - 未来需要时再升级
|
||
|
||
**具体实施：**
|
||
1. 优化前端角色切换UI（让用户知道这是切换显示，不是真正的多身份）
|
||
2. 添加"申请其他身份"入口（引导用户注册新账号）
|
||
3. 提供账号关联功能（同一手机号可以绑定多个账号）
|
||
4. 添加快速切换账号功能（记住多个账号，快速登录）
|
||
|
||
---
|
||
|
||
## ❓ 需要确认的问题
|
||
|
||
在决定是否实现多身份功能前，请回答：
|
||
|
||
1. **业务需求：** 有多少用户需要多个身份？
|
||
2. **使用场景：** 用户为什么需要多个身份？
|
||
3. **紧急程度：** 这个功能有多紧急？
|
||
4. **可接受方案：** 用户是否接受注册多个账号？
|
||
5. **开发时间：** 能否接受7-10天的开发周期？
|
||
6. **风险承受：** 能否接受可能影响现有功能的风险？
|
||
|
||
---
|
||
|
||
**总结：**
|
||
- **难度：** ⭐⭐⭐⭐ (中高难度)
|
||
- **风险：** 🔴 高风险
|
||
- **工作量：** 7-10天
|
||
- **建议：** 保持现状，除非有强业务需求
|