# 超级嘉年华与 1.0 金库解锁：完整示例

本文用文字字段说明两条链路如何并行，以及为何不会超发。

- **原 1.0 分期解锁**：按加速方案到期逐步增加「金库已解锁」，并写分期流水。
- **超级嘉年华**：活动期内只记「活动待解锁」；活动结束后一次性加进「金库已解锁」。

结论：资金不会叠成超发（始终受「剩余锁定」封顶）；流水账与金库已解锁可能对不上，差额看活动「已入账」。

---

## 角色与初始状态

用户小王：1.0 迁移用户，已选**加速解锁方案**。

| 含义 | 数值 |
|------|------|
| 金库原始总额 | 1000 |
| 已解锁金额 | 50（加速第 1 期刚解锁过，5%） |
| 已兑换金额 | 0 |
| 已解锁期数 | 1 |
| 下次分期解锁时间 | 大约 30 天后 |
| 剩余锁定 | 1000 − 50 = **950** |
| 当前可兑换（已解锁未兑） | 50 |

活动：**超级嘉年华**（示例窗口：当天 00:00～19:00，东七区）。

规则摘要：

- 每成功 1 个直系 2.0 用户**生涯首次升到 Lv2**，按原始总额 +10%
- 最多计 10 人（100%）
- 活动结束才真正写入金库「已解锁」
- 实际入账不超过当时「剩余锁定」

---

## 阶段一：活动开始（00:00）

| 含义 | 数值 |
|------|------|
| 金库已解锁 | 50 |
| 活动有效邀请人数 | 0 |
| 活动目标比例 | 0% |
| 活动待解锁 | 0 |
| 活动已入账 | 0 |
| 活动是否已结算 | 否 |

分期解锁定时任务**照常**跑；嘉年华**还不改金库**。

---

## 阶段二：上午 10:00，第 1 个下级升到 Lv2

只改**活动表**，不改金库：

| 含义 | 变化 |
|------|------|
| 活动有效邀请人数 | 0 → **1** |
| 活动目标比例 | **10%** |
| 理论可解锁 | 1000 × 10% = 100 |
| 不能超过剩余锁定 | min(100, 950) = 100 |
| 活动待解锁 | **100** |
| 金库已解锁 | 仍是 **50**（没动） |
| 用户可兑换 | 仍是 **50**（待解锁还不能兑） |

页面上通常会看到：已解锁基数约 50，待解锁 100。

---

## 阶段三：中午，常规分期第 2 期到期

加速第 2 期：按原始总额的 **10%** = 100。

**分期解锁**发生：

| 含义 | 变化 |
|------|------|
| 解锁流水 | 新增一笔：第 2 期、金额 100 |
| 金库已解锁 | 50 → **150** |
| 已解锁期数 | 1 → **2** |
| 下次分期解锁时间 | 再推约 30 天 |
| 剩余锁定 | 950 → **850** |

随后系统**重算活动待解锁**（避免待解锁比剩余锁定还大）：

| 含义 | 结果 |
|------|------|
| 活动有效邀请人数 | 仍是 1 |
| 理论 | 100 |
| 活动待解锁 | 仍是 **100**（100 ≤ 剩余 850，不变） |

展示侧也会按「当前剩余锁定」现场计算待解锁，与库内重算口径一致。

---

## 阶段四：下午，又有 2 个下级升到 Lv2（合计 3 人）

| 含义 | 变化 |
|------|------|
| 活动有效邀请人数 | 1 → **3** |
| 活动目标比例 | **30%** |
| 理论可解锁 | 1000 × 30% = 300 |
| 活动待解锁 | min(300, 剩余锁定 850) = **300** |
| 金库已解锁 | 仍是 **150** |
| 用户可兑换 | 仍是 **150** |

到这里为止：分期已经给了他 150；嘉年华还欠着一笔「账面上的 300」，**没进金库**。

---

## 阶段五：19:00 活动结束，结算入账

结算步骤：

1. 确认活动**尚未结算**
2. 按当前金库再算一遍待解锁，并用**剩余锁定**封顶
3. 把待解锁加进金库已解锁
4. 清空待解锁，记下活动已入账，标记**已结算**
5. **不写**分期解锁流水，**不增加**已解锁期数（避免和分期期号冲突）

结算后：

| 含义 | 数值 |
|------|------|
| 金库已解锁 | 150 + 300 = **450** |
| 剩余锁定 | **550** |
| 活动待解锁 | **0** |
| 活动已入账 | **300** |
| 活动是否已结算 | **是** |
| 已解锁期数 | 仍是 **2**（没变） |
| 分期流水合计 | 50 + 100 = **150** |
| 用户可兑换 | **450**（假设还没兑过） |

对账公式：

> 金库已解锁 450 = 分期流水合计 150 + 活动已入账 300

流水表合计与金库已解锁对不上是**预期现象**，差额看活动「已入账」。

之后再跑结算任务：已结算则直接跳过，不会重复加。

---

## 阶段六：活动结束后，原分期继续

下一次到期仍按「原始总额 × 比例」，再和剩余锁定取小：

| 期次 | 本期想解 | 剩余锁定 | 实际解 | 解完后已解锁 | 解完后剩余 |
|------|----------|----------|--------|--------------|------------|
| 第 3 期 | 100 | 550 | 100 | 550 | 450 |
| 第 4 期 | 100 | 450 | 100 | 650 | 350 |
| … | … | … | … | … | … |
| 最后一期 | 按规则 | 很少时 | 把剩余一次性解完 | **1000** | **0** |

全部解完后：标记**解锁完成**，清空下次分期时间；分期任务不再动这个用户。

总额始终封顶为金库原始总额（本例 1000），不会因为「分期 + 嘉年华」解出超过原始总额。

若结算时一次把剩余锁定全部入账（例如满 10 人且当时还锁着很多），会直接标记解锁完成并清空下次分期时间，后续分期不再跑。

---

## 全程对照表

| 时刻 | 金库已解锁 | 剩余锁定 | 活动待解锁 | 活动已入账 | 用户能兑多少（未兑过） |
|------|------------|----------|------------|------------|------------------------|
| 活动开始前 | 50 | 950 | 0 | 0 | 50 |
| 第 1 人升 Lv2 | 50 | 950 | 100 | 0 | 50 |
| 分期第 2 期 | 150 | 850 | 100 | 0 | 150 |
| 共 3 人升 Lv2 | 150 | 850 | 300 | 0 | 150 |
| 19:00 结算后 | 450 | 550 | 0 | 300 | 450 |
| 以后分期… | 逐渐增加 | 逐渐减少 | 0 | 300 | 跟着已解锁走 |
| 全部解完 | 1000 | 0 | 0 | 300 | 1000 − 已兑 |

---

## 并发简例（结算与分期撞车）

同一秒：结算要给小王加 300，分期也正好要解第 3 期 100。

- **先跑分期**：已解锁 150→250；结算再读到剩余锁定 750，仍可加 300 → 最终 550（正确）
- **先跑结算**：已解锁 150→450；分期本轮可能因并发冲突失败，下一分钟按新的剩余锁定再跑

不会出现「两边各加一遍导致超过当时剩余锁定」的超发；最多某一轮跳过、下一轮补。

---

## 容易误解的两点

1. **活动期间**：待解锁只是预告，不能兑换；只有结算进金库后才能兑。
2. **和纯分期比**：同样时间点，小王多拿了活动那 300，会比没参加活动的人更早解完；但最后总数仍是金库原始 1000，不是 1000 + 300。

---

## 与 C 端文档的关系

接口字段与联调说明见：[super_carnival_frontend.md](./super_carnival_frontend.md)。