1. 用户身份体系：通过 openid 作为小程序唯一用户 ID，分销上下级、优惠券归属、拼团团员全部靠 openid 绑定；
2. 数据存储层：分为主业务库（订单、用户、分销关系、券记录）+ Redis 缓存（热门拼团、优惠券库存、分销佣金临时计算）；
3. 通信链路：前端操作 → 逻辑层 JS → 后端 API 校验 → 数据库读写 → 返回渲染层展示；
4. 风控拦截层：所有优惠、分佣、拼团成团逻辑不在前端计算，全部后端二次校验，防止用户篡改前端数据薅羊毛。

一、优惠券技术实现逻辑（最基础营销模块）

1. 核心数据表结构（后端底层）

1. 优惠券模板表（商家后台创建）
   存储通用规则：满减 / 折扣 / 无门槛、使用门槛、有效期、总发放库存、每人限领张数、适用商品分类、是否可叠加、核销渠道（线上 / 到店）
2. 用户持有券表（领券生成单条记录）
   主键：券 ID + 用户 openid；记录领取时间、过期时间、状态（未使用 / 已核销 / 已过期 / 已作废）
3. 核销流水表
   核销订单号、对应券 ID、抵扣金额、核销时间、门店 ID，用于对账、售后退款返还优惠券逻辑

2. 完整执行流程

步骤 1：用户领券

1. 小程序前端点击「领取优惠券」，携带券模板 ID 传给后端；
2. 后端多重校验：
   • 模板是否下架、是否过期、总库存是否充足；
   • 当前用户已领数量是否达到单人上限；
3. 校验通过：扣减模板总库存，在用户持有券表新增一条有效券记录；
4. 返回前端提示领取成功，个人卡包实时刷新（缓存同步）。

步骤 2：下单自动匹配优惠券

1. 结算页请求后端，传入用户 openid、购物车商品、实付金额；
2. 后端查询该用户全部未过期、未使用优惠券；
3. 规则过滤：匹配商品类目、满足满减门槛、判断是否支持叠加；
4. 按最优抵扣排序（优先大额满减）返回前端展示可选优惠券。

步骤 3：核销与退款返还

1. 用户提交订单选中优惠券，后端锁定该券状态为「占用」；
2. 支付成功 → 状态更新为「已核销」，写入核销流水；
3. 订单全额退款：后端自动生成返还逻辑，恢复优惠券（限制是否可二次领取）；部分退款则优惠券不予退回。

3. 关键技术防坑设计

1. 库存并发锁（Redis）：多人同时抢限时券，防止超发；用缓存锁控制库存扣减，避免数据库超卖；
2. 前端不可信原则：抵扣金额、券有效性绝不靠前端计算，全部后端重算；抓包修改优惠参数直接拦截；
3. 过期自动清理：定时任务每日批量更新过期券状态，减少查询压力。

二、拼团技术底层实现（多人成团限时营销）

1. 核心数据表

1. 拼团活动模板表
   成团人数（2 人 / 5 人）、拼团价、原价、活动时段、总库存、单人限购次数、是否允许老带新、超时自动解散时长（24h）
2. 拼团订单主表（团单）
   团 ID、发起人 openid、目标成团人数、当前团员数量、状态（拼团中 / 已成团 / 已过期解散）、创建截止时间
3. 团员明细表
   绑定团 ID + 每个参与用户 openid、各自子订单号、支付状态

2. 完整业务技术流程

阶段 1：发起拼团

1. 用户点击「发起拼团」，提交商品 ID、活动 ID；
2. 后端校验活动有效、用户未达限购；创建一条拼团主单（拼团中），同时生成该用户子订单；
3. 用户支付成功后，写入团员表，当前团员数 = 1；
4. 生成拼团分享图，携带唯一团 ID，分享到微信群 / 好友。

阶段 2：好友参团

1. 好友点开分享链接，前端携带团 ID 请求后端；
2. 后端校验：团是否存在、是否拼团中、是否未超时、该用户是否已加入该团；
3. 校验通过，生成子订单，支付成功后团员数量 + 1；
4. 后端判断：当前团员数 == 目标成团人数
   • 满足：团状态改为「已成团」，所有订单锁定发货；
   • 不满足：返回前端展示还差 X 人。

阶段 3：超时自动解散

1. 后台定时任务（每 30 分钟执行一次）扫描所有「拼团中」且超过时效的团单；
2. 批量将团状态改为「已解散」；
3. 自动发起全额退款，原路退回所有团员支付金额；清空团员记录。

3. 核心技术难点解决方案

1. 并发成团竞争：多人同时加入最后一个名额，通过数据库事务锁保证不会出现超员；
2. 库存管控双层校验：活动总库存 + 实时团人数双重限制，避免超卖；
3. 分享链路追踪：分享链接携带团唯一 ID，区分不同拼团，不会出现团员串团；
4. 缓存加速：热门爆款拼团信息存入 Redis，减少频繁查库造成页面卡顿。

三、分销技术底层逻辑（上下级分佣、裂变拉新）

1. 核心数据表

1. 用户分销关系表（核心）
   openid、上级推荐人 openid、二级上级、绑定时间、绑定来源（分享商品 / 海报）、是否锁定上下级（终身绑定 / 30 天有效期）
2. 分销商品配置表
   商品一级佣金比例、二级佣金比例、是否参与分销、佣金上限
3. 分销订单佣金记录表
   订单 ID、下单用户、一级分销商、二级分销商、各自佣金金额、佣金状态（待结算 / 已结算 / 售后扣回）
4. 分销商资金账户表
   用户总佣金、可提现余额、已提现总额、提现申请流水

2. 上下级绑定技术规则（两种主流实现）

模式 A：临时绑定（30 天有效，主流电商）

1. A 分享商品给 B，B 首次点开小程序时，后端检测 B 无上级；
2. 自动把 A 写入 B 的上级，A 的上级作为 B 二级上级；
3. 30 天内 B 下单，A、A 上级均可拿佣金；30 天后重新绑定新推荐人。

模式 B：终身锁定（本地门店私域）

技术关键点

• 绑定动作仅在新用户未注册 / 无上级时触发；老用户打开别人分享链接，不修改原有上级；
• 关系存储在独立分销关系表，全局唯一，分销、订单、佣金全部关联此表。

3. 下单分佣完整计算流程

1. 用户提交支付订单，后端获取下单人 openid；
2. 查询分销关系表，取出一级、二级推荐人；
3. 查询当前商品分销佣金比例，基于实付金额（剔除优惠券、运费）计算一级、二级佣金；
4. 新增佣金记录，状态标记「待结算」（默认确认收货 7 天后可结算，防止退款亏损）；
5. 同步增加上级分销商账户待结算佣金。

4. 结算、提现、售后扣回逻辑

1. 自动结算：定时任务处理已确认收货满 7 天订单，将「待结算」佣金转为可提现余额；
2. 用户提现：前端发起提现申请，后端校验可提现余额，生成提现单，调用微信商户转账 API 打款到微信零钱；
3. 售后退款佣金追回：订单发生全额 / 部分退款，后端反向扣减对应分销商佣金；若佣金已提现，标记欠款，下次产生新佣金自动抵扣。

5. 平台强制风控技术（微信小程序硬性限制）

1. 层级限制：微信官方仅允许二级分销，后端强制限制最多两级，三级及以上直接拦截，防止判定传销导致小程序封禁；
2. 黑名单机制：批量注册小号刷佣金的账号，后端风控识别 IP、设备、openid 规律，冻结分佣权限；
3. 数据日志全留存：所有上下级绑定、分佣、提现流水永久存储，供平台审核；
4. 禁止诱导强制分享：前端不能弹窗强制分享才能领佣金，接口层增加校验拦截。

四、三者共用关键底层通用技术（商家必懂，影响稳定性）

1. 前后端分离校验机制（防作弊核心）

• 前端只做展示、收集参数，无权修改价格、佣金、券状态；
• 抓包篡改参数、伪造分享关系、修改抵扣金额，后端校验不通过直接拒绝。

2. 缓存 Redis 作用

• 优惠券库存、热门拼团、分销商余额高频读写数据放缓存，减轻数据库压力，页面加载更快；
• 并发锁解决超领券、超员拼团、超量分佣问题。

3. 定时任务（后台自动执行）

4. 小程序身份链路串联

五、三者技术成本 & 性能对比（商家落地参考）

六、极简总结（一句话看懂各自底层本质）

1. 优惠券：基于模板生成用户独立券凭证，下单后端校验门槛自动抵扣，靠库存锁防止无限领券；
2. 拼团：创建独立团单记录团员，定时任务管控超时自动解散退款，靠事务锁控制成团人数；
3. 分销：以 openid 绑定永久 / 临时上下级关系，订单完成后按商品比例自动生成两级佣金，配套提现与售后追回风控，严格遵守平台二级限制。