《7日签到活动》系统规则文档
文档版本：V1.0编写人：系统策划实习生适用项目：7日签到活动系统文档用途：交付程序开发使用
一、活动开放条件
1. 玩家成功创建角色后，即自动开启7日签到活动。
2. 活动持续周期为创建角色当日（第1日）起至第7日止，共计7个自然日。
3. 活动面板在玩家创建角色后即可在主界面看到入口图标。
4. 活动结束后的入口图标置灰并保留24小时，供未领取玩家进行补领；24小时后入口消失。
二、签到天数计算规则
2.1 创建角色日定义
玩家创建角色的当天定义为第1日（SignDay = 1）。服务器以玩家角色创建时间戳（CreateTimestamp）为基准进行计算。
2.2 刷新时间
每日凌晨4:00:00（服务器时间）为签到天数刷新节点。玩家每日可签到的天数计算公式：
当前签到天数 SignDay = 当前日期 - 创建日期 + 1（日期以每日4:00为分界点计算，4:00前属于前一天）
2.3 跨天判定逻辑
以服务器时间为准，凌晨4:00:00前属于前一天，4:00:00及之后属于新一天。示例：玩家在周一凌晨3:50打开面板，此时仍属于周一的签到天数；4:00后系统刷新，变为周二的签到天数。
2.4 天数上限
SignDay 取值范围为1~7。超过第7日后，活动状态变为"已结束"。
三、每日领奖规则
3.1 领取顺序
奖励必须按天数顺序依次领取（第1日→第2日→…→第7日），不可跳领。
3.2 四种状态定义
表1：奖励状态定义
| 状态 | 条件 | 客户端表现 |
| 可领取 | 当前日期 ≥ 该天数 且 该天数奖励未领取 | 奖励格高亮，领取按钮可点击 |
| 已领取 | 该天数奖励已成功领取 | 奖励格显示已领取标记，领取按钮置灰 |
| 不可领取 | 当前日期 < 该天数 | 奖励格锁定，领取按钮不可点击 |
| 可补领 | 当前日期 > 该天数 且 该天数奖励未领取 且 活动未结束 | 奖励格显示补领标记，领取按钮可点击 |
3.3 领取前置校验
服务器在发放奖励前需校验：
1. 该天数 ≤ 当前可签到天数
2. 该天数奖励未被领取（去重校验）
3. 前一天的奖励已领取（顺序校验，补领场景除外）
四、补领规则
4.1 补领条件
当前日期已超过某天数，但该天数的奖励未领取。活动仍在进行中（即未超过第7日）。前序天数的奖励已全部领取完毕（保证顺序）。
4.2 补领方式
玩家打开活动面板后，可补领的天数奖励格显示特殊补领标识。玩家点击该天数的领取按钮，服务器校验通过后直接发放奖励，不消耗任何道具或货币。补领必须按顺序进行，即如果第3天和第4天都可补领，必须先补领第3天，再补领第4天。
4.3 活动结束后处理
活动结束后（第7日结束后），不可补领。未领取的奖励视为放弃，系统不做任何补偿。
五、奖励发放规则
5.1 发放方式
奖励直接发放到玩家背包（游戏内邮箱作为备用通道）。每天最多包含3种奖励，每种奖励有独立的ID和数量。
5.2 背包满处理
发奖前服务器校验背包剩余容量。若背包容量充足：直接发放到背包。若背包容量不足：通过游戏内邮箱发放，并提示玩家"背包已满，奖励已发放至邮箱，请及时领取"。
5.3 重复领取限制
服务器端为每位玩家维护一张签到记录表（sign_record），字段包含：role_id、sign_day、is_claimed、claim_timestamp。每次领取操作前，服务器查询该玩家对应天数的is_claimed状态。若is_claimed = 1，直接拒绝请求，返回"该奖励已领取"。领取成功后，立即将is_claimed置为1，并记录claim_timestamp。
六、客户端负责内容
表2：客户端负责内容
| 序号 | 负责内容 | 说明 |
| 1 | 活动面板UI展示 | 展示7天奖励格、当前状态、按钮 |
| 2 | 状态图标显示 | 根据服务器返回的状态数据展示对应图标（可领取/已领取/不可领取/补领） |
| 3 | 点击事件上报 | 玩家点击领取按钮时，向服务器发送领取请求，携带天数参数 |
| 4 | 等待与反馈 | 请求发出后展示Loading，收到响应后展示结果动画或提示 |
| 5 | 领取成功表现 | 播放领取成功的动画效果，更新奖励格状态 |
| 6 | 提示文案展示 | 展示各类提示信息（如"背包已满"等） |
| 7 | 红点提示 | 有可领取奖励时，活动入口显示红点 |
客户端不负责任何判定逻辑，所有状态数据均来自服务器下发。
七、服务器负责内容
表3：服务器负责内容
| 序号 | 负责内容 | 说明 |
| 1 | 活动开启判定 | 判断玩家是否创建角色，是否在活动周期内 |
| 2 | 签到天数计算 | 根据服务器时间计算玩家当前签到天数 |
| 3 | 领取状态管理 | 维护每位玩家的签到记录表，校验是否可领取/已领取/不可领取 |
| 4 | 顺序校验 | 校验前置天数是否已领取，保证领取顺序 |
| 5 | 奖励发放 | 校验背包容量，执行发奖或邮箱投递 |
| 6 | 去重校验 | 防止同一奖励被重复领取 |
| 7 | 补领逻辑校验 | 判断是否满足补领条件 |
| 8 | 活动结束判定 | 判断活动是否已结束，结束后拒绝所有领取请求 |
| 9 | 配置表读取 | 读取奖励配置表，获取每日奖励内容 |
八、异常处理
表4：异常处理方案
| 异常场景 | 处理方案 |
| 断网 | 客户端在请求发出后设置10秒超时；超时后提示"网络异常，请重试"；服务器若已处理请求但客户端未收到响应，玩家重新点击时服务器根据is_claimed状态返回正确结果，不会重复发奖 |
| 重复点击 | 客户端在收到服务器响应前，领取按钮置为不可点击状态（防连点）；服务器端通过is_claimed状态做二次校验，即使重复请求也只发一次奖 |
| 卡顿/Loading超时 | 客户端Loading超过10秒后自动隐藏，提示"请求超时，请重试"；按钮恢复可点击状态 |
| 客户端与服务器数据不一致 | 每次打开活动面板时，客户端向服务器请求最新签到状态数据并刷新界面；不使用客户端本地缓存的状态数据 |
| 服务器发奖失败 | 服务器在发奖过程中出现异常时，将is_claimed回滚为0，允许玩家重新领取；同时记录错误日志，便于后续排查和人工补发 |
| 配置表缺失/错误 | 服务器在读取配置表时若发现某天数配置缺失，拒绝该天数的领取请求，返回"活动配置异常，请联系客服"；同时触发告警通知运维人员 |