签到、福利与兑换码

Definition

签到（Daily Check-in）是按自然日累进领取的福利轨：连续签到或累计签到给阶梯奖励。福利是运营向发放的补充轨：按活动、按补偿、按规则（邮件/邮件附件）发放。兑换码（Redeem Code）是外部入口换取奖励的凭证核销：一段码换一笔奖，需防爆破与限领。三者的共同结构：一个可领取状态 + 一次领取动作 + 一条防重规则。

Problem

发放的坑按出现顺序：

重复领取：签到按钮连点、重连重放、多端并发，同一份奖励领两次。
补签与断签口径：断签后连签计数归零还是保留？补签消耗什么、补几天上限？没有口径就只能临时拍板，规则漂移。
邮件附件过期与堆积：福利邮件不领不退，附件时效过期后玩家投诉「我没收到」；邮件无上限则背包式堆积。
兑换码爆破：码空间小、无频率限制，被脚本枚举刷光限量奖励。
发放与对账脱节：运营手动补发走调用方直接扣加，没有凭证与流水，查账无凭。

Algorithm

签到：服务端日窗口 + 领取凭证

签到状态按月/按轮次维护，领取是提交动作：

text

checkin_state:
  player:        u1001
  round:         202610            # 轮次，按服务器日
  streak:        6                 # 连签计数
  last_claim:    20261008          # 上次领取的服务器日
  claimed:       [20261001..20261008]   # 已领日期集合

领今日(20261009):
  if last_claim == today: reject（重领）
  gap = today - last_claim
  streak = (gap == 1) ? streak+1 : 1   # 断签口径：归零（可配置为保留）
  claim → 写凭证 (player, checkin, today) → 落库

「今天」按服务器日判定（与体力与次数门控同一口径），不按玩家本地时区
领取按 (player, round, day) 幂等：连点、重放、多端并发都只领一次
断签口径做成配置：「归零重来」激励连续，「累计不清」更宽松——两种都常见，选一种写死
补签（补领断掉的日）是消耗性动作：消耗道具补一天，受「补几天/月」上限约束，补签本身也走凭证

邮件与福利：发放即落邮件，领取才入账

福利发放走邮件对象而非直接入账：

环节	口径
发放	运营/系统生成邮件，附件是奖励条目，带 `expire_at`
领取	玩家操作「领取附件」，此时才写奖励凭证入账
过期	到期未领，附件回收（邮件标记过期，不可再领）
上限	邮件数量封顶，满则拒收新邮件或挤掉最旧（口径固定）

邮件是发放与入账解耦的缓冲：发放不落背包，领取才落——补偿、活动奖、系统通知共用一路
邮件附件领取与登入签到共用「领取凭证 + 幂等键」，不各写一套
全服邮件（所有玩家一份）与个人邮件分开处理：全服邮件用模板 + 惰性生成，不给每个玩家写一行

兑换码：核销、限领与防刷

text

redeem_code:
  code:        XMAS2026-XXXX
  rewards:     [ {item: gem, n: 500} ]
  per_user:    1               # 每人限领
  quota:       100000          # 全服限量
  claimed:     41200
  expire_at:   2026-12-31

核销(玩家提交码):
  1. 频率限制（同账号/IP 单位时间尝试次数）
  2. 码存在且未过期
  3. 该玩家未领过（per_user 去重）
  4. 全服配额未满（quota 递减）
  5. 写凭证 (player, code) 入账

顺序即防线：先限流再判存在，爆破付出频率代价；限领与配额在同一事务里判并自增，不先发奖后查配额
码不带语义、不可预测（否则能被推出未公开码），一码一奖或一码多奖但每人限领是两种独立形态
核销全走凭证：哪个人、什么码、发了什么、什么时候，流水可查——兑换争议的唯一凭据

与运营侧接线

发放源收敛到一处出账，玩家侧多个领取入口：

入口	发放源	领取形态
签到面板	签到表	按日领取
邮箱	运营/系统	领附件
兑换码	外部（媒体/活动）	核销即领
补偿	运营工单	邮件发放

各入口的奖励都先落凭证再入账，运营看的是同一本账。

Used By

原神 / 崩坏：星穹铁道（商业手游）：签到（米游社签到）、邮件时效与「一键领取」、兑换码（直播/活动发放，限量每人一次）——三类运营发放并存的公开形态参照。
FGO（商业手游）：连续登录奖励与累计登录奖励分开为两条轨道——「连签」与「累计」两种口径并存的参照。
梦幻西游 / 大话西游（商业端游网易）：节日福利邮件与兑换码核销的长期运营实践，作为防重与流水可查的参照。
通用开源服务端（TrinityCore、Nakama 等）：邮件与兑换码属业务层能力，Nakama 提供通用存储与远程过程调用可承载核销逻辑，但不内置签到/兑换业务口径——本页为口径归纳，具体以各项目公开文档为准。

可参考分析：原神三类运营发放=可参考（入口与发放源分离落「与运营侧接线」）；FGO 双轨登录=可借鉴（连签与累计两种口径，落签到的两种配置）；网易端游兑换流水=可参考（核销凭证落兑换码一节）；Nakama 远程过程调用承载核销=可借鉴（落兑换码实现路径，本页未展开实现细节）。

关系链：签到窗口 → 邮件解耦 → 兑换核销 → 统一出账。逐段回答「为什么需要下一个」：

签到定了「按日累进」的基本盘，才谈其它发放形态——它是最简的「状态 + 领取」。
签到够用了才要邮件——发放与入账解耦，补偿与活动奖才有统一容器。
邮件容器有了才收兑换入口——外部码核销后走同一入账，不另起一条账路。
四条入口并了才谈对账——所有发放先落凭证，运营查的是同一本账。

上游：结算（领取/核销凭证）、体力与次数门控（服务器日窗口同一口径）；下游：任务系统（签到/福利可作为任务事件源）、掉落与概率设计（发放奖励的数值侧）、运营侧活动与战令（发放的运营容器，战令见同组节点）。

Reference

本页为机制归纳；商业案例的签到/兑换规则以各自官方公开信息为准，本页只引口径不引数值。
兑换码防爆破与概率公示类合规口径以最新监管规定为准，本页给的是通用做法。
术语对照：Check-in（签到）、Streak（连签）、Mail/Attachment（邮件/附件）、Redeem Code（兑换码）、Quota（配额）、Idempotency Key（幂等键）。

签到、福利与兑换码 ​

Category ​

Definition ​

Problem ​

Algorithm ​

签到：服务端日窗口 + 领取凭证 ​

邮件与福利：发放即落邮件，领取才入账 ​

兑换码：核销、限领与防刷 ​

与运营侧接线 ​

Used By ​

Related ​

Reference ​