### [红包雨 · 限时抢：定时开场的两个积分玩法，开抢即定金额、抢完即止](https://guaqi.com/en/topic/78060)

**Published:** 2026-10-09T07:55:49

**Author:** 星动优创

**Excerpt:** 这个插件解决的是「让站里有个固定时间点会热闹一下」这件事。它塞了两个玩法：一个是红包雨——整场有一个总瓜分额，…

这个插件解决的是「**让站里有个固定时间点会热闹一下**」这件事。它塞了两个玩法：一个是**红包雨**——整场有一个总瓜分额，点「开抢」之后红包往下掉，你点中几滴就拿几滴；另一个是**限时抢**——固定名额，谁先点谁拿，抢到就是固定的一笔。

两个玩法最大的区别在「钱什么时候定」：**红包雨的金额在你点下「开抢」的那一瞬间，服务端就已经把一个数字算好存起来了**，客户端只负责把动画演给你看——所以你点得快还是慢，_收益完全一样_；而**限时抢才是真的拼手速**，名额是先到先得。

场次不用你手动张罗：**按固定间隔自动开，一场完了等下一场，页面上有倒计时**；碰上节日想临时加一场，管理员用带密钥的排障接口就能立刻开。

## 一、两个玩法，都是「限时开场」

面板分三页：红包雨、限时抢、战绩。三页共用同一套积分、日额度和记录体系，装一次就都有了。

|     |     |     |     |
| :--- | :--- | :--- | :--- |   
| **玩法** | **怎么玩** | **金额什么时候定** | **有没有名额限制** |
| 红包雨 | 点「开抢」叫下红包，点中掉落中的红包，抢满自动结算 | **点「开抢」那一刻就定了** | 有总池上限，但没有固定名额；池子发完就没了 |
| 限时抢 | 场次开始时点「抢！」，立刻出结果 | 规则固定，抢到就是那么多 | **有，先到先得，抢完即止** |

默认节奏是这样（全部可调，见第十一节）：

|     |     |     |
| :--- | :--- | :--- |  
| **项** | **红包雨（默认）** | **限时抢（默认）** |
| 多久开一场 | 每 30 分钟一场 | 每 60 分钟一场 |
| 一场持续多久 | 60 秒 | 5 分钟 |
| 每场总共发多少 | 3000 积分（整场总池） | 30 个名额 × 50 积分 |
| 单人单场上限 | 200 积分 | 一人一场一次，固定 50 积分 |
| 每人每天总上限 | 500 积分（两种玩法合在一起算） |     |

注意最后一行：**日额度是两种玩法共用的**。红包雨抢够了 500，限时抢也一起到顶，反之亦然。这是故意的，防止有人两边来回薅。

## 二、红包雨：金额在点「开抢」那一刻就定了

这是整个插件最容易被误解、也最关键的设计，值得单独说清楚。

很多人第一反应是「点红包嘛，不就是拼手速，点得快拿得多」。**这里不是这样。**流程是这样的：

1.  **你点「开抢」**：服务端当场决定这一把你拿多少分——先算一下你还剩多少额度、池子里还剩多少、单人上限是多少，取三者里最小的那个，然后把这个数**随机拆成几滴**（3 到 8 滴之间），存进你自己的记录里。
    
2.  **红包往下掉**：你看到的雨滴动画，是客户端在这个已经定好的份数上演出来的，**金额本身根本不下发到浏览器**。
    
3.  **你点中红包**：点满约定的滴数（页面底部会显示「已抢 3 / 5」），延迟不到半秒自动结算。
    
4.  **结算才揭晓**：这时候服务端把之前存好的那个数写进你的积分账户，并把「本场抢到 46 积分」和「每滴明细」显示出来。
    

所以：**红包雨里点得快慢完全不改变你拿到多少**。动画好不好看点得爽不爽是一回事，钱是另一回事。页面上那句提示原话就是：「金额在你点「开抢」那一刻就由服务端算好了，点得快慢不影响收益；限时抢才是真拼手速。」

**为什么要这么设计？**因为「按下开抢 → 结果已定」这个顺序，把一整类作弊手段直接掐死在了源头：改请求参数没用（金额本来就不从请求来）、机械连点没用（点得快不加钱）、开着脚本狂点也没用。**客户端从头到尾在钱这件事上一个字都说不上**，它只负责演动画和把「我点满了」这个事实告诉服务端。

## 三、每一次拆包，都像真红包一样有大有小

「把 200 分拆成 5 滴」如果不讲究，最省事的做法就是平均分，每人每滴都是 40。那样拆出来的红包一眼假：滑下来五张一模一样的票子，一点都不像过年。

所以这里的拆法是这样的（每滴至少 1 分，**加起来必须恰好等于总额，不会多也不会少**）：

```
设：总额 total，要拆成 parts 滴（parts 默认在 3 ~ 8 之间随机）

对第 i 滴：
  slots = 还没拆的滴数
  avg   = floor(剩余总额 / slots)          ← 剩余部分的平均值
  cap   = max(1, floor(avg × 1.7))          ← 单滴软上限：均值的 1.7 倍
  max   = min(cap, 剩余总额 − (slots − 1))  ← 再留够后面每滴至少 1 分
  take  = 在 [1, max] 里随机取一个
  这一滴 = take，剩余总额 −= take

最后一滴直接拿走剩下的全部（保证不剩零头）
```

效果就是：**前面几滴可能偏大，越到后面自然收窄**，偶尔蹦出一个特别大的、也偶尔蹦出一个特别小的——和拆真红包那种「手气好、手气差」的感觉一致。而且因为每步都留了「后面每滴至少 1 分」的余量，**绝不会出现拆到一半没钱了的情况**，总额守恒是写死在算法里的。

## 四、限时抢：名额先到先得，抢到就是你的

红包雨是「人人有份、各拿各的」，限时抢反过来：**名额是有数的，谁先点谁拿，抢完就等下一场。**

规则很直白：

|     |     |
| :--- | :--- | 
| **项** | **说明** |
| 名额  | 默认每场 30 个，页面显示「剩余名额 11 / 30」 |
| 奖励  | 抢到就是固定的一笔（默认 50 积分），不分大小 |
| 一次机会 | 一人一场只能抢一次，抢过这一场就显示「本场已抢过」 |
| 日额度 | 和红包雨共用同一个每日上限（默认 500） |
| 名额抢完 | 按钮变成不可点的「名额抢完了」，等下一场 |

**顺序上有个讲究：先占名额，再写积分。**名额是竞争资源，如果先给钱再扣名额，两个请求同时进来就可能双双超发；反过来先占名额再写积分，万一写积分这一步失败了，系统会把这笔钱**记进一个「待补发」的清单**，你下次打开页面读数据的时候自动给你补上——**名额已经占住了，就绝不会吞掉你这一份**。这一点在第八节还会再展开。

## 五、场次引擎：定时场不用你管，还能临时手动加一场

「场次」是这个插件里另一个值得说的设计。**没有「当前场次」这么一条记录存在数据库里**——那样的话全站的人同时开场就要抢着写同一条数据，很别扭。

这里的做法是「**算出来的，不是存出来的**」：

```
场次号 = 玩法名 + ":" + floor(当前时间 ÷ 场次间隔) × 场次间隔

举例（红包雨，间隔 30 分钟 = 1800 秒）：
  现在时间 1793282420
  → floor(1793282420 ÷ 1800) × 1800 = 1793282400
  → 场次号 = "rain:1793282400"

这个 1793282400 就是「本场开始的时间戳」，加 60 秒就是本场结束点。
```

好处是：**任何人、任何时刻、在世界的哪个地方算出来，结果都一模一样**。所以「全站共享同一场」这件事是天然成立的，不需要任何同步，也不会因为并发写坏了时序。

场次的区间是**左闭右开**：从开始的这一秒算在内，到「开始 + 时长」那一秒结束。时长默认必须短于间隔（这条在服务端是强制的），否则场次首尾相接，就失去「限时」的意义了。

那想临时加一场怎么办？——**管理员手动开的那一场，优先级比定时场更高，且只在进行中有效，过期自动失效。**适合节日、整点活动这种「应景」的场合，用排障接口一句话就能开（见第十节）。

## 六、防作弊：客户端在钱这件事上一个字都说不上

这类「抢福利」的玩法，最怕的就是被人当提款机。这里的闸门是这么设的：

|     |     |
| :--- | :--- | 
| **风险** | **处理方式** |
| 改请求参数多拿钱 | 客户端能提交的**只有一个可选的 requestId**，没有任何金额、份数、池子的入口；钱只从服务端配置读 |
| 点红包点得快就多拿 | 金额在点「开抢」时就定死并存在服务端，**动画点得再快也是那个数** |
| 机械连点刷积分 | 每场每人只有一次机会（场次号写进「已参与」名单）；每次动作带一次性 `requestId`，**10 分钟幂等窗口**内同一个 id 只生效一次 |
| 并发把池子/名额端走 | 所有写操作都在**命名锁**里做，锁内重新读一遍池子与额度再决定发多少 |
| 拿到负载伪造界面金额 | 开抢时下发的内容**只有「要抢几滴」和有效期**，一个金额字段都没有；结算才把数字交出来 |
| 重复结算（多点一次结算按钮） | 发放带固定的 `source_key`（红包雨是 `rain:场次:用户`），**重试不重复发** |
| 浏览器里改规则 | 所有钱规则**只读服务端配置**，模块设置里放的都是钱规则以外的展示开关——第十一节细说 |

## 七、界面上你会看到什么

模块拖进页面后长这样（自上而下）：

|     |     |
| :--- | :--- | 
| **区块** | **内容** |
| 顶部状态条 | 「我的积分」当前余额、今日已抢进度、今日还能抢多少 |
| 三个选项卡 | 红包雨 / 限时抢 / 战绩 |
| 场次卡（每个玩法各一张） | 大倒计时——进行中显示还剩几秒，没开场显示距离下一场还有多久；临时手动开的场会打一个「临时场」角标 |
| 红包雨 · 开场前 | 本场还剩多少 / 总共多少、已参与人数、每人每场上限，一个大按钮「开抢」 |
| 红包雨 · 抢的过程中 | 一块「红包雨来了」的舞台，红包从上往下掉，进度显示「已抢 3 / 5」，点满自动结算 |
| 红包雨 · 结算后 | 「本场抢到 46 积分」+ 每滴明细（9 / 6 / 14 / 8 / 9 这样一排小票） |
| 限时抢 · 进行中 | 剩余名额进度条 + 「剩余名额 11 / 30」，按钮「抢！」 |
| 限时抢 · 抢完 / 抢过 | 按钮变灰，文案分别是「名额抢完了」和「本场已抢过」 |
| 战绩页 | 总收益 / 参与场次 / 最佳单场 / 红包雨 / 限时抢 五格汇总 + 最近 8 条明细 |
| 规则区 | 把两种玩法的间隔、时长、总额、名额、日上限直接写在页面上，用户不用问 |

游客看到的是「登录后就能抢红包，抢到的积分直接进账户」和一个「去登录」按钮，点了会拉起站点自己的登录弹窗，不会跳走。

## 八、发钱失败也不会吞你一分

「先到先得」最怕的是抢到了名额、钱却没到账。所以这里做了三层兜底：

1.  **占位顺序**：限时抢一定是**先占名额，再写积分**。名额占住了，说明这一份已经是你的了。
    
2.  **待补发清单**：写积分失败（比如某个账户写入出错）时，把这笔钱连同玩法、场次号挂进一个清单，**并且当场告诉用户「积分这会儿没记上，稍后会自动补上」**——不糊弄。
    
3.  **读状态时自动补发**：只要用户下次打开页面读一次数据，系统顺手把清单里属于他的那几条重新发一遍，发成功就移出清单，没成功继续挂着。发的时候同样带固定 `source_key`，所以**补发一百次也不会重复发**。
    

红包雨那边是另一种保障：开抢时用掉的那部分额度是当场算好并写进你自己记录的，结算失败只会提示「再点一次结算」，而且发放的 `source_key` 是固定的，所以**反复重试不会重复到账，也绝不会因为你手抖点快了点慢了就少发**。

## 九、安装（按顺序做）

拿到安装包：`guaqi-rain-arena-1.0.0.zip`（40.6 KB）。

1.  **上传**：进 WordPress 后台的**瓜奇插件管理页**上传 ZIP。首次上传只安装，**不自动启用**。
    
2.  **开开关**：在插件列表里，把「红包雨 · 限时抢」在你要用的那个前端网站上启用（按前端网站独立启停）。
    
3.  **拖到页面上**：进 builder，从模块里把「红包雨 · 限时抢」**拖进任意页面**（模块型插件，不是表单型，首页、文章页、侧栏区块都能放）。
    
4.  **点发布**：这一步务必别漏——builder 里改完必须点「发布」，前台才会生效。
    
5.  **验收**：见下一节。
    

## 十、装完怎么验收

用带密钥的调试接口一次看完全部体检信息（当前配置、当前/下一场的起止时间、场次进度表、手动场、你的会话与战绩）：

```
mutation {
  gqRainDebug(input: { key: "gqrain-diag-3e9b47a1c52d", action: "status" }) {
    result
  }
}
```

`action` 还支持四个运维动作，省得你去数据库里手动改：

|     |     |
| :--- | :--- | 
| **action** | **作用** |
| `status`（默认） | 体检：读一遍配置、场次时间窗、进度表、手动场、会话与战绩 |
| `config` | 改规则，可带 `rainInterval` / `rainDuration` / `rainPool` / `rainPerUser` / `grabInterval` / `grabDuration` / `grabStock` / `grabReward` / `dailyCap` |
| `open` | **立刻手动开一场**（优先级高于定时场），可带 `game`（`rain` 或 `grab`）、`duration`，以及该玩法对应的 `pool` / `perUser` 或 `stock` / `reward` |
| `clear` | 清空场次进度表（把池子和名额还回去）与所有手动场，**不动任何人的积分** |
| `reset` | 重置当前用户的战绩 / 记录 / 额度 / 已参与名单 / 未结算会话（**不动积分**） |

想临时插一场红包雨、60 秒、总额 500 分，一句话就够：

```
mutation {
  gqRainDebug(input: {
    key: "gqrain-diag-3e9b47a1c52d"
    action: "open"
    game: "rain"
    duration: 60
    pool: 500
    perUser: 100
  }) {
    result
  }
}
```

**Config 型动作有句话要说在前头**：调试接口改完配置后，**本次请求内还是旧值**（配置在单次请求里被记忆化了），下一次请求才生效。这不是 bug，是为了避免「改一半的配置被用到一半」。

前端调用的接口是 `gqRainState`（读状态）、`gqRainOpen`（红包雨开抢）、`gqRainSettle`（红包雨结算）、`gqRainGrab`（限时抢抢占名额），都不需要密钥，走正常的登录身份校验。**其中只有开抢/结算/抢这三种动作接受一个可选的** `requestId`**，此外不接受任何业务参数**——金额相关的东西一律不进请求体。

## 十一、什么能调，什么不能调

这里有个刻意的分工，**关系到你的站会不会被人钻空子**：

|     |     |     |     |
| :--- | :--- | :--- | :--- |   
| **配置项** | **在哪改** | **默认值** | **硬上限** |
| 是否显示场次卡 | builder 里的模块设置 | 显示  | —   |
| 是否显示战绩记录 | builder 里的模块设置 | 显示  | —   |
| 是否显示规则说明 | builder 里的模块设置 | 显示  | —   |
| 红包雨场次间隔 | **仅服务端**（调试接口 / 过滤器） | 1800 秒（30 分钟） | 60 ~ 86400 秒 |
| 红包雨场次时长 | **仅服务端** | 60 秒 | 10 ~ 600 秒，且必须短于间隔 |
| 红包雨每场总池 | **仅服务端** | 3000 分 | 10 万分 |
| 红包雨单人单场上限 | **仅服务端** | 200 分 | 2000 分，且不超过每场总池 |
| 限时抢场次间隔 | **仅服务端** | 3600 秒（60 分钟） | 60 ~ 86400 秒 |
| 限时抢场次时长 | **仅服务端** | 300 秒（5 分钟） | 30 ~ 1800 秒，且必须短于间隔 |
| 限时抢每场名额 | **仅服务端** | 30 个 | 500 个 |
| 限时抢单次奖励 | **仅服务端** | 50 分 | 500 分 |
| 每人每日总上限 | **仅服务端** | 500 分 | 5000 分 |
| 红包雨的滴数范围 | 固定（3 ~ 8 滴） | 3 到 8 | —   |
| 未结算会话有效期 | 固定  | 300 秒 | —   |

**为什么钱规则不给 builder 改？**因为模块设置是**浏览器可以伪造的**。如果总池、名额、奖励从页面上传过来，任何人改一下请求参数就能把自己的单场额度调到天上、把名额调成无限。**所以钱规则一律只认服务端配置**，而且读出来之后还要再夹一次天花板（上面表里那些上限）——就算有人能改数据库，也不可能把奖励调到把站里积分掏空。builder 里能调的，只有三个「展示类」开关。

想用代码接管规则也可以，挂过滤器即可（服务端仍会再夹一次天花板）：

```
add_filter('guaqi_rain_rules', function ($rules) {
    $rules['rainPool']    = 8000;   // 每场总池（服务端仍会夹到 100000）
    $rules['rainPerUser'] = 300;    // 单人单场上限（仍会夹到 2000，且不超过总池）
    $rules['grabStock']   = 50;     // 每场名额（仍会夹到 500）
    $rules['dailyCap']    = 800;    // 每人每日上限（仍会夹到 5000）
    return $rules;
});
```

## 十二、常见问题

**Q：装了但页面上什么都没有？**  
按顺序查三步：插件在你这个前端网站上是不是启用状态 → builder 里模块有没有拖进页面 → builder 有没有点「发布」。三步缺一步都不显示。

**Q：红包雨一直没开场，是不是坏了？**  
先看场次卡上的倒计时。默认红包雨是每 30 分钟一场、每场只有 60 秒，所以大部分时间都在「下一场」状态，这是正常的。想验证效果，用排障接口 `action: "open"` 立刻开一场。

**Q：我点红包点得飞快，为什么拿的还是一样的？**  
因为红包雨的金额在点「开抢」那一刻就由服务端定死了，点得快慢不影响收益。真正拼手速的是限时抢——那边名额是先到先得的。

**Q：为什么抢到的红包有大有小？**  
这是设计好的。每次拆包都会在「剩余平均值」附近随机，单滴的软上限是平均值的 1.7 倍，所以会出现偏大或偏小的几滴，像拆真红包一样。但整场总额是守恒的，不会多也不会少。

**Q：能不能靠改参数多拿点？**  
改不了。客户端能提交的只有一个可选的 requestId，金额、份数、池子都不从请求来；页面上也看不到任何金额字段——开抢时下发的只有「要抢几滴」。

**Q：结算时提示「积分这会儿没记上」怎么办？**  
红包雨再点一次「结算」即可；限时抢会显示「稍后会自动补上」，你下次打开页面读数据时会自动补发。两种情况都用固定的发放标识，**重复重试不会重复到账，也不会丢掉这一份**。

**Q：想搞整点活动怎么办？**  
用排障接口 `action: "open"` 手动开一场，优先级高于定时场、且只在进行中有效，过期自动失效，不会污染你的常规节奏。

**Q：升级会不会丢数据？**  
不会。配置和场次进度存在服务端（选项表），个人记录、会话、战绩存在各自用户身上，覆盖安装新版本即可。

**Q：游客点「去登录」没反应？**  
已确认这个按钮会真的拉起站点登录弹窗（沿用平台标准登录桥）。如果你的前端域名和源站不是同一个域，需要在 nginx 上把 `/graphql` 反代到源站——这是本站踩过的坑，写在这里省你一轮排查。

## 十三、给站长的两句实话

第一，**它是「定时定点热闹一下」的工具，不是常驻小游戏**。红包雨一场只有 60 秒、限时抢更是一场最多 30 个名额，它的价值在于制造「整点有人抢」的节奏感，而不是让人天天泡在里面。建议把它放在首页显眼位置，并且在社区发个帖子告诉大家「几点几点有红包」——**有人守着倒计时，这个玩法才成立**。

第二，**额度宁可先小后大**。默认配置（红包雨每场 3000 分、限时抢每场 30 个名额、日上限 500 分）是偏保守的起步值，几乎不会让积分体系失速。先跑一两周看数据，再决定要不要用排障接口把总池或日上限往上抬——抬容易，收回来难，用户会记得你调低过。

**合规提醒：**这个玩法的积分**只能靠站内行为获得，不可提现、不可兑换现金、不可转让**；页面上的规则（场次间隔、总额、名额、每日上限、抢完即止）建议保持可见；红包雨的金额机制（开抢即定、点得快慢不影响收益）也建议在页面上讲清楚，省得用户误会是手速游戏。积分透明 + 没有现金出口 + 规则公示，这三条能挡掉绝大多数麻烦。下载地址：[https://8maoku.com/article/3488](https://8maoku.com/article/3488)

![红包雨 · 限时抢：定时开场的两个积分玩法，开抢即定金额、抢完即止](http://7b2.com/wp-content/themes/b2/Assets/fontend/images/default-img.jpg "20261009152609424-0907426bd8-1")



**Comments:** 

**春哥:** 老哥高产！



---