回放、观战与裁决

Category

server / sync 子树。节点定位：回放是同步体系最诚实的验收标准——记录方式与同步模型一起定、证据链、观战不是转发、仲裁与玩家回放分开。

Definition

回放和观战看起来像附加功能，实际上它们是同步体系最诚实的验收标准。一个系统如果无法稳定重建关键对局过程，就很难证明自己的裁决可信，也很难支撑赛事、举报处理、客服工单和线上复盘。很多团队以为这些能力可以后补，结果一旦底层没留下可重建的证据，后面几乎补不起来。

Problem

无法稳定重建对局过程，就无法证明裁决可信，赛事、举报、客服、复盘全无支撑；底层不留可重建的证据，事后几乎补不起来。回放常被当附加功能，实际它是验收标准。

为什么回放不是锦上添花

玩家投诉、比赛争议、外挂举报和结算质疑，最后都会追问同一件事：当时到底发生了什么。只保存最终结果不够，因为争议往往出在过程里：

• 某次技能到底有没有命中。
• 某个控制是不是被净化了。
• 某个玩家是不是在关键帧断线。
• 某次伤害是正常暴击还是异常触发。

没有过程证据，团队最终只能拿日志碎片和模糊录像硬猜。

回放记录方式为什么必须和同步模型一起定

不同同步模型，对回放的天然友好度并不一样：

• 帧同步或锁步：输入回放更自然，但极度依赖确定性。
• 服务端权威状态同步：状态和事件回放更常见，但要设计好快照粒度。
• 混合模型：通常需要输入、事件和快照联合记录。

因此，回放能力不能在同步模型确定以后完全不回头看。它本来就是同一条设计链路上的东西。

常见的三种回放记录方式

输入流回放

记录整局输入序列，再依赖同一套逻辑重新模拟战斗。

优点是体积轻、和帧同步天然契合。缺点是对确定性要求极高，一点分叉都会把整段回放带偏。

状态快照回放

周期性记录关键状态，回放时按快照重建过程。

优点是更直观、对完全确定性的依赖较低。缺点是存储成本更高，也更考验状态裁剪设计。

输入加检查点混合

这是很多真实项目更稳妥的选择：定期保存检查点，检查点之间记录输入或关键事件。这样既不用对超长时间完全依赖输入重演，也不会把存储打爆。

一条像样的证据链至少应该覆盖什么

比较稳妥的回放或裁决证据链，通常至少包含：

• 房间基础信息和版本信息。
• 初始状态或最近检查点。
• 输入序列、关键事件或状态增量。
• 关键帧号和时间戳。
• 裁决结果，例如命中、伤害、死亡和资源变化。
• 掉线、重连、托管和暂停这些链路事件。

如果没有这些，很多争议是无法严格解释的。

观战不是“把房间数据再发一遍”

观战的目标和回放并不一样。回放更关注复现，观战更关注实时性、带宽、公平和隔离。常见问题包括：

• 观战者延迟多少才合理。
• 是否允许看到战争迷雾、隐藏信息和选手视角。
• 观战链路能否影响主对局性能。
• 观战数据是直接走主房间广播，还是有独立转发层。

如果直接把观战旁挂在主房间广播上，房间性能和带宽通常会一起受影响。

仲裁证据和玩家回放不是一回事

工程上最好把下面两件事分开：

• 仲裁证据：给客服、风控、研发和赛事仲裁使用，强调准确和可追责。
• 玩家回放：给内容传播和复盘体验使用，强调可看性和加载效率。

前者可以更硬、更原始；后者通常需要做表现重建、UI 整理和观看体验优化。混在一起做，往往两边都做不好。

回放、重连和观战最好复用同一批底层设施

这些能力虽然用途不同，但底层经常可以复用同一批设施：

• 状态检查点。
• 输入或事件日志。
• 帧号与时序标识。
• 战斗对象序列化。
• 状态哈希和校验工具。

如果这些设施本来就是为重连恢复而设计出来的，那么回放和观战通常也会容易很多。反过来，如果重连都无法稳定恢复，回放和观战大概率也不会稳。

观战延迟和公平性不能回避

竞技性产品里，观战不是技术实现完就结束，还要回答公平问题：

• 观战是否必须延迟若干秒或若干帧。
• 观战者能不能拿到完整房间信息。
• 是否允许选手好友实时观战。
• 是否要对观战链路做隔离和审计。

这些问题如果没有提前定义，观战就会变成新的作弊面。

工具链通常比回放播放器更重要

很多团队做了回放文件，却没有真正能帮助排障的工具。比较稳妥的实践通常包括：

• 能跳到指定帧。
• 能查看该帧关键对象状态。
• 能查看技能、Buff、伤害和控制的时序。
• 能查看输入、默认输入、托管和断线记录。
• 能对比两端哈希或两次回放差异。

真正决定团队效率的，往往不是“能不能播出来”，而是“能不能查明白”。

常见误区

• 把回放当成发布后再补的内容能力，结果底层根本没有留下可重建的证据。
• 把观战实现成直接旁路主链路，最后既影响对局性能，也得不到稳定观赛体验。
• 把仲裁证据和玩家回放混成一套，结果既不够准确，也不够好看。
• 只有回放数据，没有帧级工具，出了争议以后仍然只能靠猜。

回放、观战与裁决真正要提前设计的，不是“怎么把录像播出来”，而是怎样为同步体系留下足够稳定、足够可验证的过程证据。

实战案例：一次「争议发生时，回放调不出来」的证据链后补排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「回放记录方式为什么必须和同步模型一起定」「一条像样的证据链至少应该覆盖什么」「观战不是“把房间数据再发一遍”」用到深水区：裁决要用时才发现没有证据——这是回放被当附加功能的排查，也是「回放是验收标准」的完整展开。

背景与现象：某赛事服版本迭代后，1200 局历史对局无法重建，决赛技能命中争议只能拿日志碎片硬猜，单起争议裁决耗时 3 天；观战直接旁挂主房间广播，占房间带宽 40%，对局 P99 同步上涨。

第一步：现象与口径——先看证据缺在哪一环

争议口径：1200 局旧对局缺版本与检查点信息，输入流重演在升级后分叉，命中结论不可复现。

观战口径：观战与对局共用主房间广播，赛事日房间带宽 40% 被观战占用，主对局消息排队随之变长。

第二步：分层归因——按本页证据链清单排查

回放调不出来归因  占比
  输入回放依赖确定性但版本已分叉    47%
  证据链缺检查点与链路事件          33%
  观战旁挂主房间广播                20%

逐项比对：输入流回放「一点分叉都会把整段回放带偏」，版本升级后正中这一点；证据链缺「初始状态或最近检查点」与「掉线、重连、托管和暂停」两类；观战直接走主房间广播。三类都在，确定性分叉那条占比最大。

第三步：根因——回放被当成了发布后再补的内容能力

本页 Problem 说得直接：回放常被当附加功能，实际它是验收标准；底层不留可重建的证据，事后几乎补不起来。同步模型定型时没有回头看记录方式，证据链六项缺了两项；观战也没单独设计——如果直接把观战旁挂在主房间广播上，房间性能和带宽通常会一起受影响。裁决、性能、观赛三头一起塌。

第四步：处置与回填——把证据链前置到同步设计

1. 记录方式随同步模型同定：改用输入加检查点混合记录，定期保存检查点，检查点之间记输入与关键事件。
2. 证据链六项补齐：房间版本、检查点、输入事件、帧号时间戳、裁决结果、断线重连事件逐项落盘。
3. 观战独立转发：观战走独立转发层并强制延迟，不再旁挂主房间广播；仲裁证据与玩家回放分两套产出。

复核账：可重建对局 0% → 100%；单起争议裁决 3 天 → 2 小时；观战占房间带宽 40% → 9%；赛事日主对局 P99 恢复到预算内。

回填清单：

回填项	动作	回填处
记录方式同定	同步模型确定时同步定回放记录方式，混合记录打底	回放记录方式为什么必须和同步模型一起定
证据链六项	版本、检查点、输入事件、帧号时间戳、裁决结果、链路事件逐项落盘	一条像样的证据链至少应该覆盖什么
观战独立转发	观战走独立转发层与延迟，不旁挂主房间广播	观战不是“把房间数据再发一遍”
仲裁与回放分离	仲裁证据求准确可追责，玩家回放求可看性	仲裁证据和玩家回放不是一回事

案例的三个教训

1. 回放是验收标准，不是内容功能。底层不留可重建的证据，事后几乎补不起来。
2. 记录方式必须和同步模型一起定。同步模型定型后再回头补记录，中间的版本分叉足以让整段回放带偏。
3. 观战不是“把房间数据再发一遍”。旁挂主链路既拖垮房间性能，也给观战留下新的作弊面。

Used By

回放系统设计；举报仲裁的证据链；观战延迟与公平性处理。

Related

关系链：验收标准 → 记录方式同定 → 三种记录 → 证据链 → 观战 → 仲裁分离 → 设施复用 → 观战延迟。上游：sync/06（确定性保证可重建）。下游：production/retro（复盘面）、operation/observability/04（故障复盘）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。