体力与次数门控

Category

system / 玩法系统（经济闸门）。节点定位：体力与次数门控把「可以无限刷的行为」变成「预算内行动」——恢复、上限、消耗、重置、限购五件事。它是经济的阀门：产出侧水龙头开多大由它控制，水龙头与水池的口径在 numerical 树的掉落与概率设计与 economy 树；消耗凭证走结算。本页只管门控机制本身。

Definition

体力（Stamina/Energy）是随时间恢复的行动资源：行为扣体力、时间回体力、上限封顶。次数门控是它的离散变体：不存资源，只按自然时间窗口（日/周）限制行为次数。两者同一本质——给玩家行动发预算。区别在存储口径：体力是余额（可部分消耗），次数是窗口计数（到窗口整体清零）。

Problem

门控的坑按出现顺序：

• 恢复计时算不清：客户端倒计时自己走，服务端也定时器自己加——两端漂移，玩家看到的恢复时间与服务端实际不一致；定时器掉线期间漏回。
• 跨天边界抖动：重置按玩家本地时区算，同一服务器内玩家「日」不同步；排行榜与日常任务的对账口径跟着乱。
• 购买与限购不幂等：买体力的支付回调重试、限购计数丢失，导致多扣或多送。
• 上限变动溢出：活动期临时加上限，活动结束体力超上限——回收还是保留，没有口径就临时拍板。
• 体力可交易：能转移的预算就是货币，工作室刷体力倒卖，经济侧防线失效。

Algorithm

恢复模型：服务端惰性结算，不靠定时器

恢复量在读取时按时间差现算，不维护每玩家的恢复定时器：

stamina_state:
  player:        u1001
  stamina:       87
  cap:           120          # 基础上限，活动 buff 可临时调
  recover_interval: 300       # 每 5 分钟回 1 点
  last_recover_ts:  2026-10-09T09:40:00Z

read 时结算:
  elapsed = now - last_recover_ts
  gain    = floor(elapsed / recover_interval)
  stamina = min(cap, stamina + gain)
  last_recover_ts += gain * recover_interval   # 只推进整倍数，余数保留

• 定时器只属于「满溢提醒」这类展示，不参与结算——服务重启、掉线都不丢恢复
• last_recover_ts 只推进整倍数：上限满了之后的时间不折算成溢出
• 上限变动（升级、活动 buff）只影响下一次结算，不回发、不回收——临时 buff 过期后超上限的部分保留，被下一次消耗自然吃掉
• 满体力后 last_recover_ts 贴齐当前时刻，避免离线一晚回来瞬间灌满的口径分歧

重置：服务器日，惰性触发

重置一律按服务器固定时区的自然日，不按玩家本地时区：

attempt_counter:
  player:      u1001
  action:      raid_entry          # 副本次数 / 商店限购 / 体力购买
  window_key:  20261009            # 服务器日，周门控用 ISO 周
  count:       2
  limit:       3

• 重置动作惰性触发：请求带上 window_key，与当前服务器日不符则先清零再判——不需要每日定时任务扫全量玩家
• 日常任务的每日重置、体力购买限购、副本次数共用这一张窗口计数表，action 区分用途
• 玩家侧的「今日剩余次数」展示从同一张表读，客户端不自行倒计时到次日——次日边界以服务器日为准

消耗与购买：凭证与幂等

• 扣体力是结算动作：先写消耗凭证 (player, action, cost, reason) 再落余额——崩溃可重放，与结算同构
• 买体力走支付回调，幂等键 (player, order_id)；限购计数在同一个事务里自增，超限则拒绝——不存在「先扣款后查限购」的窗口
• 体力不可赠送、不可交易：可转移的预算就是二级货币，工作室套利的入口；好友赠送体力类设计只送「次数」且上限很小，这是行业普遍红线而非本仓独创

门控与玩法侧的接线

门控是闸门，玩法侧只问一个问题：「这个行为有没有预算」：

行为	门控形态	窗口
刷副本	体力消耗	无窗口，余额制
副本次数	次数门控	日
购买体力	限购次数	日
竞技场挑战	次数门控	日（可购买追加）
周常任务	次数门控	周

体力消耗与日常任务联动（「消耗 100 体力」型日常）靠事件：门控层发 stamina_spent 事件，任务系统与成就订阅计数，门控层不知道任务存在。

Used By

• 原神（商业手游）：树脂体力（上限与按分钟恢复为公开数值）、浓缩树脂把「多次消耗」折叠成「一次消耗多次收益」、每日委托按服务器日重置——恢复模型与重置口径的参照。
• FGO（商业手游）：AP 体力随玩家等级成长而上限提升、升级时体力回满——上限变动不回收的参照。
• Candy Crush（商业三消）：生命值制（次数门控的时间恢复版）+ 好友赠送生命——「可赠送但限量」红线的参照。
• 率土之滨 / 三国志·战略版（商业 SLG）：行动力与政令门控大地图行为，把门控从「防刷」扩展到「节奏控制」的参照。
• 开源件口径：TrinityCore、Nakama 等通用开源服务端均不内置体力与次数门控，此类件属业务层自建——本页为口径归纳，开源侧无可直接参照的通用实现。

可参考分析：原树脂数值=可借鉴（恢复与上限口径落本页恢复模型，具体数值不抄）；FGO 升级回满=可借鉴（上限变动不回收落溢出处理）；Candy Crush 赠送=可借鉴（限量赠送红线落消耗一节）；率土/三战行动力=可借鉴（节奏控制视角，落点 design 树玩法节奏）；开源不内置=不适用（本页即自建口径的落点）。

Related

关系链：恢复模型 → 重置窗口 → 凭证消耗 → 玩法接线。逐段回答「为什么需要下一个」：

• 恢复模型定了才有稳定的「预算供给」——惰性结算保证掉线重启都不丢账。
• 供给定了才谈窗口——次数门控与每日重置共用窗口计数表。
• 窗口定了才敢扣——消耗必须走凭证，限购与支付幂等才闭环。
• 扣得干净了才接玩法——门控发事件，任务、成就、战令各取所需。

上游：结算（消耗凭证）、掉落与概率设计（体力换产出的数值侧）；下游：任务系统与成就与图鉴（消耗事件订阅）、战令与活动页（体力驱动的进度与运营闸门，待建节点）。

Reference

• 本页为机制归纳；原神/FGO/Candy Crush/率土的具体数值以各自官方公开信息为准，本页只引口径不引数值细节。
• 体力不可交易的红线为行业通行做法的归纳，非单一出处。
• 术语对照：Stamina/Energy（体力）、Cap（上限）、Recovery Interval（恢复间隔）、Server Day（服务器日）、Attempt Limit（次数门控）、Lazy Evaluation（惰性结算）。