红包雨 · 限时抢：定时开场的两个积分玩法，开抢即定金额、抢完即止

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

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

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

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

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

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

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

项	红包雨（默认）	限时抢（默认）
多久开一场	每 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