---
tags: []
aliases:
  - ER 图
date created: 星期二, 十二月 9日 2025, 10:45:43 晚上
date modified: 星期二, 十二月 9日 2025, 10:58:01 晚上
---

# ER 图

**设计思路分析:**

1. **RBAC 模型选择:** 为了满足“银行级权限控制”及“企业级样板间”的扩展性要求，我采用了标准的 **RBAC Level 1 (Flat RBAC)** 变体。虽然当前只有 3 个固定角色，但使用 **多对多 (Many-to-Many)** 的关联表 (`user_roles`) 能够支持未来某用户既是 "Editor" 又是 "TechLeader" 的混合权限场景，避免后续重构。
2. **双令牌机制落地:** 专门设计了 `refresh_tokens` 表。JWT 的 Access Token 是无状态的（不入库），但 Refresh Token 必须入库以实现“吊销”、“防重放”和“设备管理”功能。
3. **软删除与审计:** 所有核心表（`users`, `roles`）均继承了 Base Model，包含 `deleted_at` 字段。

---

## 📊 阶段二：概念验证 (Conceptual Modeling - ER Diagram)

```mermaid
erDiagram
    %% ---------------------------------------------------------
    %% 1. 用户核心表 (Users)
    %% 核心聚合根，包含认证凭证与个人资料
    %% ---------------------------------------------------------
    users {
        bigint id PK "主键"
        string username "用户名, unique, not null"
        string password_hash "Argon2/Bcrypt 哈希值, not null"
        string nickname "用户昵称 (Profile)"
        string avatar_url "头像链接 (Profile)"
        string bio "个人简介 (Profile)"
        smallint status "状态: 1=Active, 0=Banned"
        timestamptz created_at "创建时间"
        timestamptz updated_at "更新时间"
        timestamptz deleted_at "软删除时间 (Soft Delete)"
    }

    %% ---------------------------------------------------------
    %% 2. 角色表 (Roles)
    %% 存储 Admin, Editor, Subscriber 等定义
    %% ---------------------------------------------------------
    roles {
        bigint id PK "主键"
        string code "角色编码 (e.g. 'admin'), unique"
        string name "角色显示名称 (e.g. '超级管理员')"
        string description "备注"
        timestamptz created_at
        timestamptz updated_at
        timestamptz deleted_at
    }

    %% ---------------------------------------------------------
    %% 3. 用户-角色关联表 (User Roles)
    %% 中间表，实现 RBAC 多对多关系
    %% ---------------------------------------------------------
    user_roles {
        bigint user_id FK "关联 users.id"
        bigint role_id FK "关联 roles.id"
        timestamptz created_at
    }

    %% ---------------------------------------------------------
    %% 4. 刷新令牌表 (Refresh Tokens)
    %% 用于双令牌机制的续期与风控
    %% ---------------------------------------------------------
    refresh_tokens {
        bigint id PK "主键"
        bigint user_id FK "关联 users.id"
        string token_hash "Refresh Token 的哈希值 (安全考虑不存明文)"
        string family_id "令牌家族ID (用于检测重用/Rotation)"
        string parent_token_id "父令牌ID (用于溯源)"
        boolean is_revoked "是否已撤销 (黑名单机制)"
        timestamptz expires_at "过期时间 (7天)"
        timestamptz created_at
    }

    %% ---------------------------------------------------------
    %% 关系定义 (Relationships)
    %% ---------------------------------------------------------
    
    %% 一个用户可以拥有多个 Refresh Token (多设备登录)
    users ||--o{ refresh_tokens : "has_many (sessions)"

    %% 一个用户可以拥有多个角色 (扩展性设计)
    users ||--o{ user_roles : "assigned_to"
    
    %% 一个角色可以包含多个用户
    roles ||--o{ user_roles : "includes"
```

---

## 🔑 关键关系业务含义说明

1. **Users `||--o{` Refresh Tokens (1 对 多):**
    
    - **业务含义:** 一个用户可以在多个设备（手机、PC）同时登录。
    - **风控逻辑:** 当用户执行“修改密码”或“严重违规封号”时，后端会根据 `user_id` 批量将该用户下的所有 `is_revoked` 设为 `true`，从而实现**强制下线**。
    - **令牌轮转:** `family_id` 和 `parent_token_id` 用于检测令牌复用攻击。如果一个旧的 RT 被使用，系统可以根据 `family_id` 级联作废整个令牌链。
        
2. **Users `}|--|{` Roles (多 对 多，通过 `user_roles`):**
    
    - **业务含义:** 虽然 PRD 定义了三个层级，但物理模型采用“多对多”设计是架构上的**防御性编程**。
    - **场景:** 如果未来需要赋予某个 Editor 临时的 Admin 权限，或者创建一个 "SuperSubscriber"（付费会员），我们只需在 `user_roles` 插入一条记录，而无需修改表结构。
        
3. **Users 表的混合设计:**
    
    - **决策:** 我没有将 `Profile` (昵称/头像) 拆分为独立表。
    - **理由:** 遵循“勿增实体”原则。在当前 V1 阶段，Profile 字段较少（仅 3 个），且在列表页展示时（如“评论列表”）属于高频连表查询。合并不仅减少了 JOIN 开销，也简化了 GORM 的模型编写。