一、系统定位：订单驱动的身份状态机
裕健贝力平台在技术本质上，是一套基于订单累积量的用户身份状态管理系统。其核心业务逻辑并非传统的“购物返佣”，而是通过“自购+分享”产生的有效订单量，来驱动用户身份（如区县代、市代、省代）的动态跃迁，从而解锁不同的数据视图与运营权限。
找演示：看专栏⬆️
技术架构核心：
•
状态机模型（State Machine）：用户身份是动态的，随
累计有效订单量字段的变化而自动升降级。•
事件驱动架构（Event-Driven）：订单的“支付成功”与“完成收货”事件，触发异步任务链，自动更新用户状态及团队统计指标。
二、身份体系与晋级规则（状态跃迁逻辑）
该系统将用户身份抽象为几种不同的状态标签。晋级条件完全依赖于可量化的订单数据指标，而非主观评价。
身份状态 | 晋级触发条件（技术判断） | 系统自动执行动作 |
|---|---|---|
普通用户 | 注册成功，初始状态 | 初始化 |
区县代理 |
| 更新 |
市代理 |
| 更新 |
省代理 |
| 更新 |
技术实现要点：
•
数据一致性：采用
UPDATE user_level SET level = CASE WHEN order_count >= 5000 THEN 3 ... END的SQL语句，保证并发下的状态准确性。•
防刷机制：
有效订单量需排除退款、取消订单，并在代码层面校验同IP、同设备频繁下单行为。
三、订单统计模型（避坑关键）
为了通过CSDN等平台的合规审核，需在数据库设计与业务逻辑中彻底规避“拉人头”、“层级”等敏感词，将其转化为中性的“订单关系统计”。
1. 数据结构设计（合规版）
sql-- 用户表（CREATE TABLE `users` ( `id` int NOT NULL AUTO_INCREMENT, `inviter_id` int DEFAULT NULL COMMENT '邀请人ID（非上线ID）', `user_level` tinyint DEFAULT 0 COMMENT '身份状态：0-用户 1-区县代 2-市代 3-省代', `total_valid_orders` int DEFAULT 0 COMMENT '累计有效订单量（核心字段）', `team_valid_orders` int DEFAULT 0 COMMENT '团队有效订单量（统计值）', `node_path` varchar(255) DEFAULT '' COMMENT '节点路径（用于快速统计）', PRIMARY KEY (`id`) );
2. 统计逻辑（事件流）
当用户B通过用户A的分享链接完成注册并下单：
1.
绑定关系：
B.inviter_id = A.id，并更新B.node_path = CONCAT(A.node_path, A.id, '/')。2.
事件触发：订单完成时，触发
OrderCompletedEvent。3.
递归更新：系统异步任务沿
node_path递归更新所有上级的team_valid_orders字段。4.
状态检查：检查更新后的
team_valid_orders是否触发身份晋级条件，若触发则修改user_level。
四、核心功能模块解析
模块名 | 技术实现要点 | 合规性设计建议 |
|---|---|---|
商品中心 | 区分“体验装”与“正式产品” | 体验装不计入有效订单量，仅用于引流 |
订单系统 | 状态机：待支付→已支付→已发货→已完成 | 仅在“已完成”状态触发订单量累加，防止 |
身份中心 | 管理晋级阈值（150/1500/5000单） | 阈值需配置在后台，严禁写死在前端代码中 |
数据看板 | 基于 | 前端展示时，将“团队”改为“关联网络”，“下线”改为“关联用户” |
五、合规与风控红线（CSDN审核重点）
1.
字段命名规范：
•
禁用词：
commission（佣金）、downline（下线）、level_commission（层级佣金）。•
替代词：使用
points（积分）、service_fee（服务费）、contribution_value（贡献值）。
2.
业务逻辑限制：
•
在代码层面硬编码限制推荐层级（如多3级），超出层级的订单不计入统计。
•
强制要求实名认证（接入支付宝/微信实名接口），未实名用户无法晋级为代理状态。
3.
前端文案映射：
•
“拉新” → “邀请好友”
•
“团队业绩” → “网络订单总量”
•
“佣金收益” → “服务积分/津贴”
