下面继续整理成可以直接给后端开发、数据库设计和技术评审使用的《数据库 ER + 字段设计文档》。重点把 用户、会员等级、推荐关系、升级审核、商品、SKU、购物车、地址、订单、支付、积分、转账、提现、收藏、关注、浏览记录、审计日志 统一起来，同时明确主键、唯一约束、索引和状态字段。

会员推荐关系 + 新零售商城

数据库 ER + 字段设计文档

版本： V1.0
数据库建议： MySQL 8.0+
字符集： utf8mb4
排序规则建议： utf8mb4_0900_ai_ci
主键策略： BIGINT UNSIGNED / 雪花 ID 或数据库自增 ID
金额存储： BIGINT，单位“分”
积分存储： BIGINT，整数
时间： DATETIME / TIMESTAMP，建议统一 UTC 存储
软删除： 业务数据按需增加 deleted_at

1. 数据库总体设计

系统按业务域拆分：

纯文本复制⌃数据库
│
├── 用户域
│   ├── users
│   ├── user_profiles
│   ├── user_identities
│   └── user_bank_accounts
│
├── 会员域
│   ├── member_levels
│   ├── members
│   ├── member_relations
│   ├── member_upgrade_requests
│   └── member_upgrade_logs
│
├── 商城域
│   ├── categories
│   ├── zones
│   ├── products
│   ├── product_skus
│   ├── product_images
│   ├── carts
│   └── cart_items
│
├── 交易域
│   ├── addresses
│   ├── orders
│   ├── order_items
│   ├── payments
│   └── order_logs
│
├── 资产域
│   ├── point_accounts
│   ├── point_transactions
│   ├── point_transfers
│   ├── withdrawal_requests
│   └── withdrawal_logs
│
├── 用户行为域
│   ├── favorites
│   ├── follows
│   └── browsing_histories
│
└── 系统域
    ├── announcements
    ├── service_configs
    └── audit_logs

2. ER 总体关系

核心关系：

纯文本复制⌃                        ┌──────────────┐
                        │    users     │
                        │ 用户主表     │
                        └──────┬───────┘
                               │
             ┌─────────────────┼──────────────────┐
             │                 │                  │
             ▼                 ▼                  ▼
    ┌────────────────┐  ┌───────────────┐  ┌──────────────┐
    │ user_profiles  │  │    members    │  │ point_accounts│
    │ 用户资料       │  │ 会员          │  │ 积分账户     │
    └────────────────┘  └───────┬───────┘  └──────┬───────┘
                                 │                 │
                    ┌────────────┼───────┐         │
                    │            │       │         │
                    ▼            ▼       ▼         ▼
             member_levels   relations  upgrade  transactions
                                      requests
                    │
                    ▼
             upgrade_logs

users
  │
  ├─────────────── addresses
  │
  ├─────────────── orders
  │                    │
  │                    ├──── order_items
  │                    └──── payments
  │
  ├─────────────── carts
  │                    │
  │                    └──── cart_items
  │
  ├─────────────── favorites ───── products
  ├─────────────── follows
  └─────────────── browsing_histories ───── products

products
   │
   ├──── categories
   ├──── zones
   ├──── product_images
   └──── product_skus

point_accounts
   │
   ├──── point_transactions
   └──── point_transfers

users
   ├──── user_identities
   ├──── user_bank_accounts
   └──── withdrawal_requests

3. 核心设计原则

3.1 用户与会员分离

不要把所有会员字段全部塞进 users。

推荐：

纯文本复制⌃users
    ↓
members
    ↓
member_levels

原因：

用户身份：

纯文本复制⌃登录、手机号、密码、状态

会员身份：

纯文本复制⌃会员等级、会员状态、升级

属于不同业务域。

4. users 用户主表

表名：

纯文本复制⌃users

用途：

保存系统所有用户的基础身份。

status

纯文本复制⌃0 = 禁用
1 = 正常
2 = 锁定

索引

纯文本复制⌃PRIMARY KEY (id)

UNIQUE KEY uk_mobile (mobile)

KEY idx_status_created (status, created_at)

5. user_profiles 用户资料表

表名：

纯文本复制⌃user_profiles

用途：

保存非认证型资料。

约束：

纯文本复制⌃UNIQUE KEY uk_user (user_id)

6. user_identities 实名信息表

表名：

纯文本复制⌃user_identities

用途：

管理实名资料。

状态：

纯文本复制⌃0 = 未认证
1 = 审核中
2 = 已认证
3 = 认证失败

安全

身份证号不得明文存储。

推荐：

纯文本复制⌃原始值 → 应用层加密 → 数据库存储

7. user_bank_accounts 银行账户表

表名：

纯文本复制⌃user_bank_accounts

用途：

提现银行卡资料。

约束：

纯文本复制⌃KEY idx_user_status (user_id, status)

银行卡号不得明文返回接口。

8. member_levels 会员等级表

表名：

纯文本复制⌃member_levels

用途：

定义会员等级。

例如：

纯文本复制⌃1 一星会员
2 二星会员
3 三星会员

约束：

纯文本复制⌃UNIQUE KEY uk_code (code)
UNIQUE KEY uk_sort (sort)

9. members 会员表

表名：

纯文本复制⌃members

用途：

记录用户当前会员身份。

约束：

纯文本复制⌃UNIQUE KEY uk_user (user_id)
KEY idx_level (level_id)

10. member_relations 推荐关系表

表名：

纯文本复制⌃member_relations

这是整个推荐体系的核心表。

例如：

纯文本复制⌃A 推荐 B

记录：

纯文本复制⌃parent_user_id = A
child_user_id = B
relation_level = 1

如果未来支持多层团队：

纯文本复制⌃A → B → C

可以产生：

纯文本复制⌃A → B level 1
B → C level 1
A → C level 2

约束

纯文本复制⌃UNIQUE KEY uk_parent_child (parent_user_id, child_user_id)

KEY idx_parent_level (
    parent_user_id,
    relation_level,
    status
)

KEY idx_child (
    child_user_id
)

禁止：

纯文本复制⌃parent_user_id = child_user_id

11. 推荐关系为什么不建议直接放 users.referrer_id

简单系统可以：

纯文本复制⌃users.referrer_id

但本项目未来存在：

纯文本复制⌃团队
多层级
统计
团队人数
关系查询

因此建议使用独立关系表。

如果为了查询效率，也可以在 users 增加：

纯文本复制⌃direct_referrer_id

作为冗余字段。

但：

纯文本复制⌃users.direct_referrer_id

和：

纯文本复制⌃member_relations

必须由服务端事务保持一致。

12. member_upgrade_requests 升级申请表

表名：

纯文本复制⌃member_upgrade_requests

状态：

纯文本复制⌃pending
approved
rejected
cancelled

约束

同一个用户不能同时存在两个 pending。

实现方式：

可以通过应用层 + 唯一约束设计。

例如增加：

纯文本复制⌃pending_flag

然后建立：

纯文本复制⌃UNIQUE(user_id, pending_flag)

其中只有待审核状态使用固定值。

13. member_upgrade_logs 审核日志表

表名：

纯文本复制⌃member_upgrade_logs

用途：

记录升级状态历史。

例如：

纯文本复制⌃pending → approved

记录：

纯文本复制⌃operator_id
from_status = pending
to_status = approved
action = approve

14. categories 商品分类表

表名：

纯文本复制⌃categories

支持：

纯文本复制⌃一级分类
└── 二级分类

索引：

纯文本复制⌃KEY idx_parent_status (parent_id, status)

15. zones 商品专区表

表名：

纯文本复制⌃zones

用途：

新品、热销、专题等运营专区。

16. zone_products 专区商品关联表

表名：

纯文本复制⌃zone_products

因为一个商品可以属于多个专区，所以建立中间表。

约束：

纯文本复制⌃UNIQUE(zone_id, product_id)

17. products 商品主表

表名：

纯文本复制⌃products

状态：

纯文本复制⌃0 = 下架
1 = 上架
2 = 草稿

18. product_skus 商品 SKU 表

表名：

纯文本复制⌃product_skus

库存设计：

纯文本复制⌃可售库存 = stock - locked_stock

也可以直接使用：

纯文本复制⌃available_stock

但二者不要重复维护，避免数据不一致。

19. product_images 商品图片表

表名：

纯文本复制⌃product_images

类型：

纯文本复制⌃cover
gallery
detail

20. carts 购物车主表

表名：

纯文本复制⌃carts

如果每个用户只有一个购物车，可以非常简单：

约束：

纯文本复制⌃UNIQUE(user_id)

21. cart_items 购物车商品表

表名：

纯文本复制⌃cart_items

约束：

纯文本复制⌃UNIQUE(cart_id, sku_id)

加入同一 SKU 时：

纯文本复制⌃quantity += new_quantity

而不是产生重复购物车记录。

22. addresses 收货地址表

表名：

纯文本复制⌃addresses

索引：

纯文本复制⌃KEY idx_user_default (user_id, is_default)

建议保证每个用户最多一个默认地址。

23. orders 订单主表

表名：

纯文本复制⌃orders

这是商城交易核心表。

订单状态

纯文本复制⌃pending_payment
pending_shipment
shipped
completed
cancelled
refund

可以根据实际业务增加：

纯文本复制⌃refunding
refunded

订单号

纯文本复制⌃UNIQUE(order_no)

24. 为什么订单必须保存快照

订单不能只存：

纯文本复制⌃product_id

因为之后商品可能：

纯文本复制⌃改名
改价
下架
删除
修改规格

所以订单商品必须保存：

纯文本复制⌃商品名称
SKU 名称
价格
规格
图片

25. order_items 订单商品表

表名：

纯文本复制⌃order_items

索引：

纯文本复制⌃KEY idx_order (order_id)

26. payments 支付表

表名：

纯文本复制⌃payments

状态：

纯文本复制⌃pending
paid
failed
cancelled
refunded

约束：

纯文本复制⌃UNIQUE(payment_no)
KEY idx_order_status(order_id, status)
UNIQUE(provider, provider_trade_no)

第三方交易号需要允许 NULL。

27. order_logs 订单状态日志

表名：

纯文本复制⌃order_logs

operator_type：

纯文本复制⌃user
admin
system
payment
merchant

28. point_accounts 积分账户表

表名：

纯文本复制⌃point_accounts

约束：

纯文本复制⌃UNIQUE(user_id)

29. point_transactions 积分流水表

表名：

纯文本复制⌃point_transactions

这是积分系统最重要的账本表。

类型：

纯文本复制⌃recharge
reward
transfer_in
transfer_out
order_use
withdraw
freeze
unfreeze
adjustment

约束：

纯文本复制⌃UNIQUE(transaction_no)

建议增加：

纯文本复制⌃UNIQUE(reference_type, reference_id, user_id, type)

但具体唯一规则需要根据业务场景调整。

30. point_transfers 积分转账记录

表名：

纯文本复制⌃point_transfers

用于记录一次完整的 A → B 转账。

状态：

纯文本复制⌃pending
completed
failed
cancelled

约束：

纯文本复制⌃UNIQUE(transfer_no)

31. 积分转账数据库事务

完整转账：

纯文本复制⌃BEGIN

锁定发送者 point_accounts
↓
锁定接收者 point_accounts
↓
检查发送方余额
↓
扣减发送方
↓
增加接收方
↓
写 sender point_transaction
↓
写 receiver point_transaction
↓
更新 point_transfer
↓
COMMIT

不能只：

纯文本复制⌃UPDATE point_accounts

而不生成流水。

32. withdrawal_requests 提现申请表

表名：

纯文本复制⌃withdrawal_requests

状态：

纯文本复制⌃pending
reviewing
approved
rejected
paid
cancelled

33. 提现银行卡快照

提现不能只依赖：

纯文本复制⌃bank_account_id

因为用户后续可能修改银行卡。

建议同时保存：

纯文本复制⌃bank_name_snapshot
holder_name_snapshot
card_last4_snapshot

例如：

这样历史提现记录仍然能够保持当时状态。

34. withdrawal_logs 提现状态日志

表名：

纯文本复制⌃withdrawal_logs

35. favorites 收藏表

表名：

纯文本复制⌃favorites

约束：

纯文本复制⌃UNIQUE(user_id, product_id)

防止重复收藏。

36. follows 关注表

表名：

纯文本复制⌃follows

因为当前系统无法完全确认“关注”的具体业务对象，因此设计为通用结构。

例如：

纯文本复制⌃shop
brand
product
zone

约束：

纯文本复制⌃UNIQUE(user_id, target_type, target_id)

37. browsing_histories 浏览记录表

表名：

纯文本复制⌃browsing_histories

约束：

纯文本复制⌃UNIQUE(user_id, product_id)

每次浏览：

纯文本复制⌃browse_count += 1
last_browsed_at = NOW()

不需要每次都新增一条完全重复记录。

38. announcements 公告表

表名：

纯文本复制⌃announcements

39. audit_logs 审计日志表

表名：

纯文本复制⌃audit_logs

整个系统的统一操作审计表。

敏感数据不要直接写进 detail_json。

40. 服务配置表

表名：

纯文本复制⌃service_configs

例如：

纯文本复制⌃points.exchange_rate = 100
withdraw.enabled = 1
mall.enabled = 1

敏感密钥不能放在该表以明文保存。

41. 关键 ER 关系

用户与会员

纯文本复制⌃users 1 ───── 1 members

members N ───── 1 member_levels

推荐关系

纯文本复制⌃users 1 ───── N member_relations
users 1 ───── N member_relations

逻辑上：

纯文本复制⌃parent_user_id → child_user_id

升级

纯文本复制⌃users 1 ───── N member_upgrade_requests

member_upgrade_requests
       │
       ├── from_level_id → member_levels
       ├── to_level_id   → member_levels
       └── 1 ───── N member_upgrade_logs

商品

纯文本复制⌃categories 1 ───── N products

products 1 ───── N product_skus
products 1 ───── N product_images

zones N ───── N products
       ↓
zone_products

购物车

纯文本复制⌃users 1 ───── 1 carts

carts 1 ───── N cart_items

cart_items N ───── 1 product_skus

订单

纯文本复制⌃users 1 ───── N orders

orders 1 ───── N order_items

orders 1 ───── N payments

orders 1 ───── N order_logs

积分

纯文本复制⌃users 1 ───── 1 point_accounts

point_accounts 1 ───── N point_transactions

users
 └──── N point_transfers
       ├── sender_user_id
       └── receiver_user_id

提现

纯文本复制⌃users 1 ───── N withdrawal_requests

withdrawal_requests N ───── 1 user_bank_accounts

withdrawal_requests 1 ───── N withdrawal_logs

42. 数据库核心索引汇总

重点索引：

纯文本复制⌃users
├── uk_mobile
└── idx_status_created

members
├── uk_user
└── idx_level

member_relations
├── uk_parent_child
├── idx_parent_level
└── idx_child

member_upgrade_requests
├── uk_request_no
├── idx_user_status
└── idx_reviewer_status

products
├── idx_category_status
├── idx_status_sort
└── idx_created

product_skus
├── uk_sku_code
└── idx_product_status

cart_items
└── uk_cart_sku

addresses
└── idx_user_default

orders
├── uk_order_no
├── idx_user_status_created
└── idx_status_created

order_items
└── idx_order

payments
├── uk_payment_no
├── idx_order_status
└── uk_provider_trade_no

point_transactions
├── uk_transaction_no
├── idx_user_created
└── idx_reference

point_transfers
├── uk_transfer_no
├── idx_sender_created
└── idx_receiver_created

withdrawal_requests
├── uk_withdrawal_no
├── idx_user_status
└── idx_status_created

favorites
└── uk_user_product

follows
└── uk_user_target

browsing_histories
└── uk_user_product

43. 外键策略

生产环境建议根据业务和数据量决定是否使用数据库 Foreign Key。

逻辑关系必须保证：

纯文本复制⌃users.id
↓
members.user_id
↓
orders.user_id
↓
point_accounts.user_id

但对于高并发、大规模商城：

可以采用：

纯文本复制⌃数据库索引
+
应用层完整性检查
+
事务

而不是依赖大量 FK。

无论是否使用 FK，应用层都必须验证数据归属。

44. 删除策略

核心业务数据不建议物理删除。

例如：

纯文本复制⌃订单
支付
积分流水
提现
升级申请
审计日志

不能直接：

SQL复制⌃DELETE

推荐：

纯文本复制⌃status
deleted_at

或者永久保留。

45. 用户注销策略

用户注销后：

纯文本复制⌃users.status = disabled

而不是删除整个用户。

因为用户可能仍然存在：

纯文本复制⌃订单
积分流水
提现
推荐关系
审计记录

46. 会员升级事务

用户提交申请：

纯文本复制⌃BEGIN

查询 members FOR UPDATE
↓
查询是否已有 pending
↓
读取当前等级
↓
读取下一等级
↓
检查业务条件
↓
INSERT member_upgrade_requests
↓
COMMIT

审核通过：

纯文本复制⌃BEGIN

查询 upgrade_request FOR UPDATE
↓
检查 status = pending
↓
检查审核人权限
↓
检查申请人关系
↓
查询 member FOR UPDATE
↓
再次验证当前等级
↓
修改 members.level_id
↓
更新 upgrade_request
↓
INSERT member_upgrade_logs
↓
INSERT audit_logs
↓
COMMIT

47. 订单创建事务

纯文本复制⌃BEGIN

锁定 SKU
↓
检查商品状态
↓
检查库存
↓
重新计算商品价格
↓
重新计算优惠
↓
重新计算积分
↓
重新计算运费
↓
创建订单
↓
创建 order_items
↓
锁定库存
↓
清理购物车
↓
写 order_logs
↓
COMMIT

注意：

不能以浏览器提交的总金额作为订单金额依据。

48. 订单支付完成事务

支付回调：

纯文本复制⌃BEGIN

验证第三方签名
↓
查询 payments FOR UPDATE
↓
幂等检查
↓
核对订单
↓
核对支付金额
↓
更新 payment
↓
更新 order
↓
记录 order_logs
↓
COMMIT

49. 积分抵扣规则

现有系统页面显示：

纯文本复制⌃100 积分 = 1 元

建议数据库配置：

纯文本复制⌃points_to_cent = 100

例如：

纯文本复制⌃100积分 → 100分人民币
500积分 → 500分人民币

但最终允许抵扣多少，还需要配置：

纯文本复制⌃订单商品
最大抵扣比例
商品是否允许积分抵扣
用户当前积分

因此建议商品或系统配置增加：

纯文本复制⌃points_discount_enabled
points_discount_rate

50. 积分与订单的关系

订单应保存：

纯文本复制⌃used_points
points_discount_cent

例如：

纯文本复制⌃商品金额：10000分
使用积分：500
积分抵扣：500分
实际支付：9500分

同时生成：

纯文本复制⌃point_transactions
type = order_use
reference_type = order
reference_id = order_id

51. 提现业务模型

如果业务规则确实是：

纯文本复制⌃积分 → 可提现

那么建议不要简单把积分余额直接改成“钱”。

明确划分：

纯文本复制⌃point_accounts
    ↓
积分
    ↓
提现申请
    ↓
withdrawal_requests
    ↓
财务处理

这样可以避免：

纯文本复制⌃购物抵扣积分
转账积分
可提现积分

三个概念混为一谈。

如果实际上存在“现金余额”和“积分余额”两种资产，则应进一步拆成：

纯文本复制⌃asset_accounts
asset_transactions

不要继续共用一个 point_accounts。

52. 会员等级数据口径

目前前端检查发现：

纯文本复制⌃会员平台：一星会员

商城个人中心：普通会员

数据库设计上必须避免两套等级字段。

错误：

纯文本复制⌃users.member_level = 1
mall_users.level = normal
members.level_id = 1

推荐：

纯文本复制⌃members.level_id

作为唯一会员等级来源。

商城只读取：

纯文本复制⌃members.level_id

通过服务层统一转换为展示名称。

53. 推荐关系数据口径

同样不要出现：

纯文本复制⌃users.referrer_id
team.parent_id
member.parent_id

多个地方分别保存一份关系。

推荐关系唯一来源：

纯文本复制⌃member_relations

如有缓存字段：

纯文本复制⌃users.direct_referrer_id

只能作为冗余查询字段。

54. 商城商品数据口径

价格唯一来源：

纯文本复制⌃product_skus.price_cent

订单创建后：

纯文本复制⌃order_items.price_cent

作为历史成交价格快照。

即：

纯文本复制⌃实时商品价格
      ↓
product_skus

历史订单价格
      ↓
order_items

不能反过来读取当前商品价格显示历史订单。

55. 订单状态机

纯文本复制⌃                 ┌───────────────┐
                 │ pending_payment│
                 └───────┬───────┘
                         │ 支付
                         ▼
                 ┌───────────────┐
                 │pending_shipment│
                 └───────┬───────┘
                         │ 发货
                         ▼
                    ┌─────────┐
                    │ shipped │
                    └────┬────┘
                         │ 收货
                         ▼
                    ┌─────────┐
                    │completed│
                    └─────────┘

pending_payment
       │
       └──── 取消 → cancelled

非法状态转换必须拒绝。

56. 会员升级状态机

纯文本复制⌃pending
   │
   ├── approve → approved
   │
   └── reject  → rejected

要求：

纯文本复制⌃approved → 不允许再次审核
rejected → 不允许再次审核

57. 提现状态机

纯文本复制⌃pending
   ↓
reviewing
   ├── rejected
   │
   └── approved
          ↓
         paid

状态不能由客户端直接指定。

错误：

json复制⌃{
  "status": "paid"
}

正确：

纯文本复制⌃提交申请 → pending
审核 → approved
财务打款 → paid

58. 数据库事务隔离

涉及：

纯文本复制⌃订单库存
积分
提现
会员升级

建议至少考虑：

纯文本复制⌃REPEATABLE READ

并结合：

纯文本复制⌃SELECT ... FOR UPDATE

或乐观锁：

纯文本复制⌃version

具体选型由并发量和现有架构决定。

59. 并发控制

积分

使用：

纯文本复制⌃行锁
或
version 乐观锁

库存

使用：

纯文本复制⌃available_stock

更新：

纯文本复制⌃UPDATE product_skus
SET stock = stock - ?
WHERE id = ?
  AND stock >= ?

通过受影响行数判断库存是否足够。

重复订单提交

使用：

纯文本复制⌃Idempotency-Key

60. 敏感字段存储原则

以下字段建议应用层加密：

纯文本复制⌃身份证号
银行卡号

以下字段数据库中可直接保存，但接口需要脱敏：

纯文本复制⌃手机号
微信号
姓名

数据库日志不能出现：

纯文本复制⌃password
token
完整身份证
完整银行卡

61. 数据备份

至少包含：

纯文本复制⌃users
members
member_relations
member_upgrade_requests
products
product_skus
orders
order_items
payments
point_accounts
point_transactions
point_transfers
withdrawal_requests
audit_logs

重点业务表需要：

纯文本复制⌃每日备份
增量备份
异地备份
恢复演练

62. 推荐数据库分库边界

V1 不建议一开始就物理分库。

推荐逻辑分域：

纯文本复制⌃user
member
mall
order
asset
system

数据库仍可以先：

纯文本复制⌃一个 MySQL

通过表前缀/代码模块区分：

纯文本复制⌃users
members
products
orders
point_accounts

后期数据量上升再考虑：

纯文本复制⌃读写分离
分库
分表
缓存
消息队列

63. 推荐缓存

可以缓存：

纯文本复制⌃member_levels
categories
zones
product detail
service_configs
announcements

不建议直接缓存作为最终数据源：

纯文本复制⌃积分余额
订单状态
提现状态
会员等级
支付状态

这些必须最终以数据库为准。

64. 推荐 Redis 数据

例如：

纯文本复制⌃session:{user_id}

login:fail:{mobile}

rate_limit:login:{ip}

product:{id}

category:list

member:level:{id}

积分余额如果做缓存，必须有严谨的一致性方案，不建议 V1 直接引入复杂缓存账本。

65. 数据字典

用户状态

纯文本复制⌃0 disabled
1 active
2 locked

会员状态

纯文本复制⌃0 disabled
1 active

升级状态

纯文本复制⌃pending
approved
rejected
cancelled

商品状态

纯文本复制⌃draft
on_sale
off_sale

订单状态

纯文本复制⌃pending_payment
pending_shipment
shipped
completed
cancelled
refund

支付状态

纯文本复制⌃pending
paid
failed
cancelled
refunded

提现状态

纯文本复制⌃pending
reviewing
approved
rejected
paid
cancelled

66. 推荐数据库命名规范

表名：

纯文本复制⌃snake_case

例如：

纯文本复制⌃member_upgrade_requests

主键：

纯文本复制⌃id

外键：

纯文本复制⌃user_id
product_id
order_id

时间：

纯文本复制⌃created_at
updated_at

状态：

纯文本复制⌃status

金额：

纯文本复制⌃xxx_amount_cent

数量：

纯文本复制⌃quantity

积分：

纯文本复制⌃points

67. 不建议的数据设计

不建议 1：订单直接保存商品名称 ID

错误：

纯文本复制⌃orders.product_id

因为一个订单可能包含多个商品。

应该：

纯文本复制⌃orders
    ↓
order_items

不建议 2：积分只保存一个余额

错误：

纯文本复制⌃users.points

推荐：

纯文本复制⌃point_accounts
point_transactions

不建议 3：提现直接修改积分

必须产生：

纯文本复制⌃withdrawal_request
+
point_transaction

并且考虑冻结。

不建议 4：会员等级存在多个表

只允许：

纯文本复制⌃members.level_id

作为权威数据。

不建议 5：前端传价格直接入库

错误：

json复制⌃{
  "price": 99,
  "total": 198
}

服务端必须自己计算。

68. 推荐完整 ER 图

纯文本复制⌃users
│
├── 1:1 ── user_profiles
├── 1:1 ── user_identities
├── 1:N ── user_bank_accounts
├── 1:1 ── members
│           │
│           └── N:1 ── member_levels
│
├── 1:N ── member_relations
│           ├── parent_user_id
│           └── child_user_id
│
├── 1:N ── member_upgrade_requests
│           │
│           ├── from_level_id
│           ├── to_level_id
│           └── 1:N member_upgrade_logs
│
├── 1:1 ── carts
│           └── 1:N cart_items
│
├── 1:N ── addresses
│
├── 1:N ── orders
│           ├── 1:N order_items
│           ├── 1:N payments
│           └── 1:N order_logs
│
├── 1:1 ── point_accounts
│           └── 1:N point_transactions
│
├── 1:N ── point_transfers
│
├── 1:N ── withdrawal_requests
│           └── 1:N withdrawal_logs
│
├── 1:N ── favorites ── N:1 products
├── 1:N ── follows
└── 1:N ── browsing_histories ── N:1 products

categories
└── 1:N products
          ├── 1:N product_skus
          ├── 1:N product_images
          └── N:N zones
                  │
                  └── zone_products

69. V1 核心表清单

第一阶段数据库至少建立：

纯文本复制⌃users
user_profiles
members
member_levels
member_relations

member_upgrade_requests
member_upgrade_logs

categories
products
product_skus

carts
cart_items

addresses

orders
order_items
payments
order_logs

point_accounts
point_transactions
point_transfers

withdrawal_requests
withdrawal_logs

user_identities
user_bank_accounts

favorites
follows
browsing_histories

audit_logs
announcements

70. 数据库开发优先级

P0：身份与会员

纯文本复制⌃users
user_profiles
members
member_levels
member_relations
member_upgrade_requests
member_upgrade_logs

P1：商城交易

纯文本复制⌃categories
products
product_skus
carts
cart_items
addresses
orders
order_items
payments
order_logs

P1：资产

纯文本复制⌃point_accounts
point_transactions
point_transfers
withdrawal_requests
withdrawal_logs

P2：账户扩展

纯文本复制⌃user_identities
user_bank_accounts
favorites
follows
browsing_histories

P2：系统

纯文本复制⌃announcements
audit_logs
service_configs

71. 第一阶段数据库必须重点测试

用户

纯文本复制⌃重复手机号
禁用用户
软删除用户
登录 Session

推荐

纯文本复制⌃自己推荐自己
重复推荐
循环推荐
不存在推荐人
禁用推荐人

会员升级

纯文本复制⌃跨级升级
重复申请
重复审核
越权审核
并发审核
审核后再次操作

商品

纯文本复制⌃库存不足
SKU 下架
商品下架
SKU 并发扣库存

订单

纯文本复制⌃重复创建
价格改变
库存改变
支付重复回调
订单越权
订单状态非法转换

积分

纯文本复制⌃余额不足
重复转账
并发转账
负数积分
自己转给自己

提现

纯文本复制⌃资料不完整
余额不足
重复提交
重复审核
并发提现
修改银行卡后的历史提现

72. 最终数据库架构原则

系统最终必须保持以下几个“唯一数据源”：

纯文本复制⌃用户身份
→ users

会员等级
→ members.level_id

会员等级定义
→ member_levels

推荐关系
→ member_relations

商品实时价格
→ product_skus.price_cent

订单历史价格
→ order_items.price_cent

订单状态
→ orders.status

支付状态
→ payments.status

积分余额
→ point_accounts

积分历史
→ point_transactions

提现状态
→ withdrawal_requests

系统操作记录
→ audit_logs

避免同一事实在多个表中独立维护。

73. 数据一致性优先级

数据一致性优先于页面显示。

例如：

纯文本复制⌃前端显示余额 = 1000
数据库余额 = 800

最终必须以数据库账本为准。

同样：

纯文本复制⌃前端显示订单已支付
数据库订单未支付

应以支付回调验证后的服务端状态为准。

74. 推荐后续开发文档链路

数据库设计完成后，建议形成完整的技术文档链：

纯文本复制⌃01 产品需求文档
        ↓
02 页面 / 原型文档
        ↓
03 API 接口文档
        ↓
04 数据库 ER + 字段设计
        ↓
05 权限设计
        ↓
06 状态机设计
        ↓
07 测试用例
        ↓
08 部署 / 运维文档

最终前后端开发人员可以按照：

纯文本复制⌃页面
 ↓
API
 ↓
Service
 ↓
数据库

一条链路进行开发。

75. V1 数据库最终推荐架构

纯文本复制⌃                  ┌───────────────┐
                  │     users     │
                  └───────┬───────┘
                          │
         ┌────────────────┼─────────────────┐
         │                │                 │
         ▼                ▼                 ▼
     会员域             商城域            资产域
         │                │                 │
   ┌─────┼─────┐     ┌────┼─────┐      ┌────┼─────┐
   │     │     │     │    │     │      │    │     │
 levels members relation products cart order points withdraw
   │              │       │       │      │    │     │
   │              │       SKU     │      │    │     │
   │              │               │      │    │     │
 upgrade          │              items   │ transaction
 request/logs     │                      │ transfer
                  │                      │
                team                    payment
                                         │
                                       logs

                         ┌───────────────┐
                         │    system     │
                         ├───────────────┤
                         │ announcements │
                         │ audit_logs    │
                         │ config        │
                         └───────────────┘

这套结构能够覆盖当前已检查出的会员推荐、等级升级、审核、团队、商城、订单、积分、转账、提现和用户资料功能，同时给后续后台管理、商家体系、多层团队和财务审核预留扩展空间。

现在三份文档已经形成一条完整开发链：

① 页面/原型 → ② API → ③ 数据库 ER/字段。

下一步最有价值的是把这三份继续整合成一份 《完整软件开发需求规格书 PRD》，然后再往下拆成 前端任务清单、后端任务清单、数据库建表 SQL、测试用例，开发团队就可以直接按 Sprint 开始执行。