# 商城系统用户表兼容性分析报告

## 一、现有 ak_users 表结构分析

### 1. 核心字段对比

| 字段名 | 运动平台用途 | 商城系统需求 | 兼容性 | 备注 |
|--------|-------------|-------------|--------|------|
| id | 用户唯一标识 | 用户唯一标识 | ✅ 完全兼容 | UUID主键 |
| username | 用户名 | 用户名 | ✅ 完全兼容 | VARCHAR(64) |
| email | 邮箱 | 邮箱 | ✅ 完全兼容 | VARCHAR(128) |
| password_hash | 密码哈希 | 密码哈希 | ✅ 完全兼容 | VARCHAR(256) |
| phone | 手机号 | 手机号 | ✅ 完全兼容 | VARCHAR(32) |
| avatar_url | 头像 | 头像 | ✅ 完全兼容 | TEXT |
| created_at | 创建时间 | 创建时间 | ✅ 完全兼容 | TIMESTAMP |
| updated_at | 更新时间 | 更新时间 | ✅ 完全兼容 | TIMESTAMP |

### 2. 运动平台特有字段

| 字段名 | 用途 | 商城系统影响 | 处理建议 |
|--------|------|-------------|----------|
| gender | 性别 | 🔄 可选利用 | 商城可用于个性化推荐 |
| birthday | 生日 | 🔄 可选利用 | 可用于会员生日营销 |
| height_cm | 身高 | ❌ 不相关 | 保留但不使用 |
| weight_kg | 体重 | ❌ 不相关 | 保留但不使用 |
| bio | 个人简介 | 🔄 可选利用 | 可用于用户展示 |
| region_id | 所属地区 | 🔄 部分兼容 | 可用于配送区域判断 |
| school_id | 所属学校 | ❌ 不相关 | 对商城无意义 |
| grade_id | 所属年级 | ❌ 不相关 | 对商城无意义 |
| class_id | 所属班级 | ❌ 不相关 | 对商城无意义 |
| role | 用户角色 | ⚠️ 冲突风险 | 需要扩展支持商城角色 |

### 3. 商城系统缺少字段

| 字段名 | 商城需求 | 解决方案 |
|--------|----------|----------|
| user_type | 用户类型(消费者/商家/配送员) | 扩展 role 字段或新增字段 |
| status | 用户状态(正常/冻结/注销) | 新增字段 |
| real_name | 真实姓名 | 新增字段(商家认证、配送员等需要) |
| id_card | 身份证号 | 新增字段(商家/配送员认证) |

## 二、地址表缺失分析

### 1. 现状
- ❌ 运动平台没有专门的用户地址表
- ❌ 商城系统必需收货地址管理功能
- 订单中 `delivery_address` 字段使用 JSONB 存储，缺乏结构化管理

### 2. 地址表设计需求

```sql
-- 用户地址表
CREATE TABLE public.ak_user_addresses (
    id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id uuid REFERENCES public.ak_users(id) ON DELETE CASCADE,
    receiver_name VARCHAR(64) NOT NULL, -- 收货人姓名
    receiver_phone VARCHAR(32) NOT NULL, -- 收货人手机
    province VARCHAR(64) NOT NULL, -- 省份
    city VARCHAR(64) NOT NULL, -- 城市
    district VARCHAR(64) NOT NULL, -- 区县
    address_detail TEXT NOT NULL, -- 详细地址
    postal_code VARCHAR(16), -- 邮编
    is_default BOOLEAN DEFAULT false, -- 是否默认地址
    label VARCHAR(32), -- 地址标签(家/公司/学校等)
    coordinates POINT, -- 经纬度坐标
    created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
);
```

## 三、兼容性问题分析

### 1. 高风险冲突 ⚠️

#### A. 角色系统冲突
- **运动平台角色**: `student`, `teacher`, `admin` 等教育相关
- **商城系统角色**: `consumer`, `merchant`, `delivery`, `service`, `admin` 等商务相关
- **解决方案**: 
  - 方案1: 扩展 role 字段支持多系统角色 (`sport_student`, `mall_consumer`)
  - 方案2: 新增 `system_roles` JSON字段存储多系统角色映射
  - 方案3: 创建独立的用户角色关联表

#### B. 业务逻辑冲突
- **运动平台**: 强绑定学校/班级体系，基于教育场景
- **商城系统**: 基于地理位置和商业场景，无教育概念
- **影响**: 数据查询、权限控制、业务流程存在根本差异

### 2. 中等风险问题 🔄

#### A. 数据完整性
- 运动平台用户可能缺少商城必需信息(真实姓名、身份认证)
- 商城用户可能不需要运动平台的教育信息
- **解决方案**: 建立数据补全机制和可选字段策略

#### B. 性能影响
- 单表存储两套业务数据，查询条件复杂
- 索引策略需要同时优化两套业务场景
- **解决方案**: 合理设计索引，考虑分区表或读写分离

### 3. 低风险问题 ✅

#### A. 基础字段兼容
- 用户基本信息(用户名、邮箱、手机、头像)完全兼容
- 认证体系(password_hash, auth_id)可共用
- 时间字段(created_at, updated_at)格式一致

## 四、推荐方案

### 方案1: 共用方案(推荐度: ⭐⭐⭐)

#### 优点:
- 用户账号统一，单点登录
- 减少数据冗余
- 开发成本相对较低

#### 缺点:
- 业务耦合度高
- 角色系统复杂
- 性能优化困难

#### 实施步骤:
1. 扩展 `ak_users` 表字段
2. 创建 `ak_user_addresses` 地址表
3. 设计多系统角色管理机制
4. 建立数据迁移和兼容策略

### 方案2: 独立方案(推荐度: ⭐⭐⭐⭐⭐)

#### 优点:
- 业务隔离，各自优化
- 扩展性强，维护简单
- 避免相互影响

#### 缺点:
- 需要账号同步机制
- 数据可能冗余
- 初期开发成本高

#### 实施步骤:
1. 创建独立的商城用户表 `mall_users`
2. 创建商城地址表 `mall_user_addresses`
3. 建立账号同步/关联机制
4. 设计跨系统数据共享策略

### 方案3: 混合方案(推荐度: ⭐⭐⭐⭐)

#### 优点:
- 核心用户信息共用
- 业务特定数据隔离
- 平衡复杂度和效率

#### 实施策略:
- 共用 `ak_users` 核心用户表
- 创建 `mall_user_profiles` 商城用户扩展表
- 创建 `mall_user_addresses` 商城地址表
- 通过 user_id 关联，实现业务数据隔离

## 五、最终建议

### 🎯 强烈推荐：方案3(混合方案)

#### 实施细节:

1. **保持 `ak_users` 表不变**，作为用户主表
2. **新增商城扩展表**:
   ```sql
   CREATE TABLE public.mall_user_profiles (
       id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
       user_id uuid UNIQUE REFERENCES public.ak_users(id) ON DELETE CASCADE,
       user_type INTEGER DEFAULT 1, -- 1消费者 2商家 3配送员
       status INTEGER DEFAULT 1, -- 1正常 2冻结 3注销
       real_name VARCHAR(64), -- 真实姓名
       id_card VARCHAR(32), -- 身份证号
       credit_score INTEGER DEFAULT 100, -- 信用分数
       mall_role VARCHAR(32) DEFAULT 'consumer', -- 商城角色
       created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
       updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
   );
   ```

3. **创建地址表** `ak_user_addresses`(如上设计)

4. **角色管理策略**:
   - `ak_users.role` 保持运动平台角色
   - `mall_user_profiles.mall_role` 管理商城角色
   - 应用层根据业务模块使用相应角色字段

#### 优势:
- ✅ 最大化复用现有基础设施
- ✅ 避免核心用户表的破坏性修改
- ✅ 商城业务数据独立可控
- ✅ 支持用户在两套系统间自由切换
- ✅ 便于后续扩展其他业务模块

这种方案既保护了现有运动平台的稳定性，又为商城系统提供了完整的用户管理能力，是最佳的平衡方案。