问题背景
宠物伙伴系统通常横跨背包、养成、战斗和展示。玩家给宠物升级、洗技能、出战、继承、放生，背后都涉及资产变化和战斗属性变化。如果宠物只是背包里的一个 item，后期会很难处理唯一实例、成长历史、技能随机和战斗快照。
宠物应该是角色资产中的独立实例。背包只保存拥有关系或道具入口，宠物服务维护成长状态，战斗服务消费出战快照，资产服务处理消耗与返还。
下面的设计不是某个项目的完整蓝图，而是一组可以落地到架构评审和代码实现里的边界。游戏服务器的很多事故，并不是功能本身复杂到无法控制，而是第一版没有把权威状态、派生状态、配置版本和失败恢复分开。等到玩家量上来、活动频率变高、客服申诉变多，原来省掉的上下文都会变成排查成本。
架构总览
flowchart LR
Command["养成命令"] --> PetSvc["宠物服务"]
PetSvc --> State[("宠物实例状态")]
PetSvc --> Skill["技能槽规则"]
PetSvc --> Asset["材料消耗/返还"]
PetSvc --> Snapshot[("出战快照")]
Snapshot --> Battle["战斗服"]
Snapshot --> Profile["展示服务"]
这张图刻意只保留主链路。真实系统里还会接入风控、配置中心、数据仓库、客服后台和灰度发布。主链路的职责越清楚，这些旁路越容易接；如果主链路已经把规则和状态揉成一团，后面每接一个系统都会复制一段判断，最终很难保证一致。
1. 宠物实例模型
宠物实例至少需要 pet_id、template_id、owner_id、level、exp、rarity、skills、locked_flags、battle_slot、version。template_id 描述基础配置，pet_id 描述玩家拥有的唯一实例。不要把成长值写在模板上，也不要把多个同模板宠物合并成数量字段。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
2. 经验和等级
经验增加要走命令流水，记录来源、数量、前后等级、溢出处理。升级可能触发属性成长、技能解锁和任务进度。为了避免重试重复加经验，经验命令需要业务幂等键。批量喂养时先生成消耗计划和经验计划，确认后一次提交。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
3. 技能槽
技能槽通常有随机、锁定、替换和继承规则。服务器要维护每个槽的 skill_id、level、locked、source。洗技能时，锁定槽不参与随机，但锁定本身可能消耗资源。随机结果要记录 seed 或 roll_id，方便玩家质疑时查询。客户端只能展示候选结果，最终结果由服务器生成。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
4. 出战快照
战斗服不应该每次查询宠物成长状态。玩家点击出战或养成变化后，宠物服务生成 battle_pet_snapshot，包含属性、技能、外观、策略版本。战斗创建时读取快照。战斗进行中宠物升级，不应影响已开始战斗，除非玩法明确支持实时刷新。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
5. 继承与重置
宠物继承是高风险操作：A 的等级、技能或稀有度转移到 B，同时消耗材料甚至销毁 A。服务器必须先生成继承预览，展示结果和消耗；确认时使用 preview_id 幂等执行。执行后记录 before/after，客服可以还原。不要让客户端自己计算继承结果。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
6. 绑定和交易
若宠物可交易，成长状态会影响价值。交易锁定期间宠物不能升级、洗技能、出战或放生。交易服务持有 lock_id，宠物服务校验锁状态。交易完成后 owner_id 变更，同时清理原玩家的出战槽和展示快照。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
7. 展示一致性
个人主页、排行榜、战斗加载界面都可能展示宠物。可以使用 display_snapshot，和 battle_snapshot 分开。展示快照包含名称、外观、等级、稀有度，不一定包含完整战斗属性。养成变化后发布 pet_changed 事件，让展示服务刷新。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
8. 异常修复
宠物系统要能按 pet_id 查完整历史：获得、升级、洗技能、出战、锁定、交易、继承。没有历史，玩家说“我的技能被吞了”时很难处理。修复工具也应该通过宠物命令执行，不要直接改 skills JSON。
落地时要把这一段写成明确的输入输出，而不是藏在调用方约定里。输入应该包含业务 ID、请求 ID、配置版本和操作者上下文；输出应该包含状态变化、拒绝原因和后续动作。只要这些信息进入协议和日志，客户端、运营、客服和研发就能围绕同一份事实沟通。
还要提前考虑灰度。影响玩家资产、战斗公平、社交关系或长期进度的逻辑，不适合全服一次性切换。先用影子计算记录新旧结果差异，再按服务器、玩家分层或玩法入口逐步放量，是成本最低的保险。
数据模型建议
| 数据对象 | 建议字段 | 说明 |
|---|---|---|
| 命令记录 | request_id、player_id、action、status、result_ref、created_at | 让客户端重试和客服查询都有稳定入口。 |
| 主状态 | owner_id、state、version、updated_at、policy_version | 用版本号保护并发，用策略版本解释结果。 |
| 计划对象 | plan_id、source、payload_hash、status、expire_at | 适合跨服务流程，避免重试生成不同结果。 |
| 审计流水 | before、after、reason、trace_id、operator | 处理申诉、回滚和人工修复时需要。 |
| 派生快照 | snapshot_id、source_version、generated_at、ttl | 给展示和读取加速，但不能反向覆盖主状态。 |
字段不必照抄，但这些语义最好保留。尤其是 plan_id 和 policy_version，很多团队一开始觉得用不上，等到跨服、合服、活动回滚时才发现没有它们就很难解释历史结果。
并发与幂等
游戏服务器里的重复请求非常常见：移动网络重传、客户端超时重试、网关迁移、后台任务补偿、客服工具二次提交。只要一次命令可能改变玩家权益，就必须有业务幂等键。这个键最好来自业务单号或计划 ID，而不是单次 HTTP 连接，因为同一个玩家动作可能跨连接重试。
并发控制要围绕业务聚合根。玩家背包按 player_id，队伍按 team_id，家园按 owner_id，战斗房间按 battle_id，UGC 发布按 map_id + version。不要把锁粒度扩大到整个服务，也不要细到无法保护业务不变量。版本条件、短事务和命令队列都可以用，关键是让不变量有唯一守护点。
半成功必须有落点。跨服务流程不要边做边忘，应该先生成不可变计划，再推进计划状态。失败后，worker 或人工工具能看到当前卡在哪一步，并决定重试、补偿或终止。
可观测性
除了接口延迟，还要给业务状态建指标：
- 命令幂等命中率、版本冲突率、重复提交率。
- 计划对象 pending、processing、failed 的数量和停留时间。
- 按配置版本拆分的成功率、拒绝率和降级率。
- 派生快照与主状态不一致的抽样比例。
- 客服后台最常查询的拒绝原因和修复入口。
日志要串起 trace_id、request_id、plan_id 和业务对象 ID。不要只在异常时打日志，因为很多线上争议在程序看来是正常拒绝。正常拒绝也要有结构化原因，否则玩家、客服和研发都会把时间花在猜测上。
降级与恢复
降级策略要按价值分层。低价值展示可以短期使用缓存，资产写入必须明确成功或失败；可丢弃广播可以降采样，高价值结算要进入待处理队列；配置服务不可用时，可以使用本地已验证版本，但不能用未知版本继续扩大影响面。
恢复工具同样重要。一个系统如果只能自动运行，不能安全人工修复，那么迟早会在复杂事故里拖慢团队。修复工具应该读取审计和计划对象，通过同一套业务命令补偿，而不是直接改数据库字段。
架构评审清单
- 权威状态和展示快照是否分离？
- 每个改变状态的命令是否有业务幂等键？
- 配置热更新是否会改变已经开始的流程？
- 客户端断线或重试后能否查询原命令结果？
- 派生缓存失效失败时能否自我修复？
- 客服能否看到操作前后、规则版本和拒绝原因？
- 风控、合规或内容审核是否有误伤恢复路径？
- 监控能否提前发现积压和状态不一致？
小结
这类服务器系统宠物伙伴成长状态架构：经验、技能、出战与继承规则怎么设计的关键，不是把第一条正常路径写通，而是让每一次状态变化都可验证、可重试、可解释。玩家看到的是一次点击、一次切线、一次领取或一次拜访，服务器背后要处理的是身份、规则、版本、并发和恢复。
只要主状态收敛、计划对象稳定、审计足够完整，后续扩展就不会把系统拖进不可维护的泥潭。反过来，如果第一版为了快把状态散落在多个服务里，后面每一次活动和版本更新都会重复偿还这笔债。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。