这个插件解决的是「让站里有个固定时间点会热闹一下」这件事。它塞了两个玩法：一个是红包雨——整场有一个总瓜分额，点「开抢」之后红包往下掉，你点中几滴就拿几滴；另一个是限时抢——固定名额，谁先点谁拿，抢到就是固定的一笔。
两个玩法最大的区别在「钱什么时候定」：红包雨的金额在你点下「开抢」的那一瞬间，服务端就已经把一个数字算好存起来了，客户端只负责把动画演给你看——所以你点得快还是慢，收益完全一样；而限时抢才是真的拼手速，名额是先到先得。
场次不用你手动张罗：按固定间隔自动开，一场完了等下一场，页面上有倒计时；碰上节日想临时加一场，管理员用带密钥的排障接口就能立刻开。
一、两个玩法，都是「限时开场」
面板分三页：红包雨、限时抢、战绩。三页共用同一套积分、日额度和记录体系，装一次就都有了。
| 玩法 | 怎么玩 | 金额什么时候定 | 有没有名额限制 |
|---|---|---|---|
| 红包雨 | 点「开抢」叫下红包，点中掉落中的红包，抢满自动结算 | 点「开抢」那一刻就定了 | 有总池上限，但没有固定名额；池子发完就没了 |
| 限时抢 | 场次开始时点「抢！」，立刻出结果 | 规则固定，抢到就是那么多 | 有，先到先得，抢完即止 |
默认节奏是这样（全部可调，见第十一节）：
| 项 | 红包雨（默认） | 限时抢（默认） |
|---|---|---|
| 多久开一场 | 每 30 分钟一场 | 每 60 分钟一场 |
| 一场持续多久 | 60 秒 | 5 分钟 |
| 每场总共发多少 | 3000 积分（整场总池） | 30 个名额 × 50 积分 |
| 单人单场上限 | 200 积分 | 一人一场一次，固定 50 积分 |
| 每人每天总上限 | 500 积分（两种玩法合在一起算） | |
注意最后一行：日额度是两种玩法共用的。红包雨抢够了 500，限时抢也一起到顶，反之亦然。这是故意的，防止有人两边来回薅。
二、红包雨：金额在点「开抢」那一刻就定了
这是整个插件最容易被误解、也最关键的设计，值得单独说清楚。
很多人第一反应是「点红包嘛，不就是拼手速，点得快拿得多」。这里不是这样。流程是这样的：
- 你点「开抢」：服务端当场决定这一把你拿多少分——先算一下你还剩多少额度、池子里还剩多少、单人上限是多少，取三者里最小的那个，然后把这个数随机拆成几滴（3 到 8 滴之间），存进你自己的记录里。
- 红包往下掉：你看到的雨滴动画，是客户端在这个已经定好的份数上演出来的，金额本身根本不下发到浏览器。
- 你点中红包：点满约定的滴数（页面底部会显示「已抢 3 / 5」），延迟不到半秒自动结算。
- 结算才揭晓：这时候服务端把之前存好的那个数写进你的积分账户，并把「本场抢到 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 条明细 |
| 规则区 | 把两种玩法的间隔、时长、总额、名额、日上限直接写在页面上，用户不用问 |
游客看到的是「登录后就能抢红包，抢到的积分直接进账户」和一个「去登录」按钮，点了会拉起站点自己的登录弹窗，不会跳走。
八、发钱失败也不会吞你一分
「先到先得」最怕的是抢到了名额、钱却没到账。所以这里做了三层兜底：
- 占位顺序：限时抢一定是先占名额，再写积分。名额占住了，说明这一份已经是你的了。
- 待补发清单：写积分失败（比如某个账户写入出错）时，把这笔钱连同玩法、场次号挂进一个清单，并且当场告诉用户「积分这会儿没记上，稍后会自动补上」——不糊弄。
- 读状态时自动补发：只要用户下次打开页面读一次数据，系统顺手把清单里属于他的那几条重新发一遍，发成功就移出清单，没成功继续挂着。发的时候同样带固定
source_key，所以补发一百次也不会重复发。
红包雨那边是另一种保障：开抢时用掉的那部分额度是当场算好并写进你自己记录的，结算失败只会提示「再点一次结算」，而且发放的 source_key 是固定的，所以反复重试不会重复到账，也绝不会因为你手抖点快了点慢了就少发。
九、安装（按顺序做）
拿到安装包：guaqi-rain-arena-1.0.0.zip（40.6 KB）。
- 上传：进 WordPress 后台的瓜奇插件管理页上传 ZIP。首次上传只安装，不自动启用。
- 开开关：在插件列表里，把「红包雨 · 限时抢」在你要用的那个前端网站上启用（按前端网站独立启停）。
- 拖到页面上：进 builder，从模块里把「红包雨 · 限时抢」拖进任意页面（模块型插件，不是表单型，首页、文章页、侧栏区块都能放）。
- 点发布：这一步务必别漏——builder 里改完必须点「发布」，前台才会生效。
- 验收：见下一节。
十、装完怎么验收
用带密钥的调试接口一次看完全部体检信息（当前配置、当前/下一场的起止时间、场次进度表、手动场、你的会话与战绩）：
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 分）是偏保守的起步值，几乎不会让积分体系失速。先跑一两周看数据，再决定要不要用排障接口把总池或日上限往上抬——抬容易，收回来难，用户会记得你调低过。
合规提醒：这个玩法的积分只能靠站内行为获得，不可提现、不可兑换现金、不可转让；页面上的规则（场次间隔、总额、名额、每日上限、抢完即止）建议保持可见；红包雨的金额机制（开抢即定、点得快慢不影响收益）也建议在页面上讲清楚，省得用户误会是手速游戏。积分透明 + 没有现金出口 + 规则公示，这三条能挡掉绝大多数麻烦。
- 本地下载已验证可用
可用性由站点定时核验，最近一次 2026-10-09 15:29。若某个下载点不可用，可在评论区告知，我们会尽快替换。
源码安全检测报告
已检测- 请求参数直接进入执行函数未发现
- 请求参数直接进入文件包含未发现
- 变量函数执行请求参数未发现
- 请求参数批量覆盖变量未发现
- 编码载荷后执行（混淆特征）未发现
- 回连裸 IP 地址未发现
- 配置预加载文件（隐蔽后门手法）未发现
- 向文件写入 PHP 代码未发现
仅「风险项」参与评分，加固建议与来源情报只作呈现