在射击类和竞技类游戏中，死亡回放机制承担着三重任务：让玩家知道自己怎么死的，让运营有直观的举报证据，让开发者在多人同步问题上有可回溯的数据。一个刚起步的项目如果把这套机制当作简单的“录屏重放”，后期一定会因为数据量、时间同步和视角选择翻车。本文以代号 twixxel 的客户端日志录制模块为例，说明如何设计并实现一套最小可用的死亡回放系统。读完你会得到一个能在 Unity 中跑通的录制-回放闭环，以及一套可以迁移到 UE4/UE5 或其他引擎的设计思路。
1. 先搞清楚死亡回放到底要录什么
1.1 死亡回放不是录屏，而是场景状态回放
死亡回放最容易产生的误解是把屏幕渲染结果直接录下来。录屏方案有三个明显问题：文件体积大、画质吃配置、无法切换视角。更麻烦的是，屏幕录制只能记录画面，不能记录背后的数值和逻辑，比如子弹到底命中哪个部位、伤害是多少、当时速度是多少。这些信息对玩家复盘和反作弊取证都没有帮助。
真正适合游戏内嵌的死亡回放，是把死亡前一段时间内的场景状态记录下来，再在播放时重建场景。这里说的“状态”包括：
- 每个重要物体的位置、朝向、速度。
- 角色的动作状态，例如开火、换弹、奔跑、下蹲。
- 影响结果的数值事件，例如某帧发生了命中、伤害、治疗、技能释放。
回放时，播放器按时间轴把状态一帧一帧应用回场景，让画面恢复成当时的样子。这样既能自由切换视角，也能通过交互界面显示额外信息。
1.2 状态帧和事件数据各解决什么问题
状态帧是基础。它每隔固定时间采样一次所有相关物体的状态，相当于给场景拍一系列“定妆照”。回放时只需要按顺序应用这些状态，物体就能沿着大致轨迹移动。
事件数据是补充。状态帧只能保证位置连续，但无法表达“某个精确时间点发生了什么”。比如开火时子弹飞出去了，如果回放时没有在正确时间点触发开火事件，即使位置对得上，枪口火光和弹道也完全对不上。
状态帧和事件数据的分工可以这样理解：
- 状态帧回答的是“当时物体在哪里、在做什么”。
- 事件回答的是“在那个连续时间段里，具体发生了什么关键动作”。
只有状态帧，回放看起来会卡顿或细节缺失；只有事件，无法还原连续运动轨迹。两者必须配合。
1.3 本地录制和服务端录制怎么取舍
对于刚起步的项目，可以先从客户端本地录制做起。客户端录制的好处是实现简单、不增加服务端带宽压力，而且可以直接拿到本地玩家的输入和表现。缺点是客户端数据只覆盖了单个玩家视角周围的情况，而且存在被修改的风险。
服务端录制则更权威。服务端只记录它自己认可的数据，比如玩家坐标、朝向、生命值、事件日志；回放时从服务端数据重建场景。由于每位玩家看到的画面都会受延迟、预测和插值影响，服务端数据反而能提供一套统一的事实基准。
现实项目通常采用混合方案：
| 方案 | 优点 | 缺点 | 适用阶段 |
|---|---|---|---|
| 客户端本地全量录制 | 实现快，数据丰富 | 文件大，可能被篡改 | 单机Demo、验收型工具 |
| 服务端权威状态+事件 | 数据可信，跨客户端一致 | 服务器压力大，需要同步设计 | 排位、对战类核心玩法 |
| 本地录制+服务端校验 | 兼顾画面表现和反作弊 | 结构复杂，需要时间对齐 | 成熟上线项目 |
twixxel 第一阶段建议先在客户端本地录制，把回放文件保存为 JSON，方便调试。确认流程稳定后，再逐步把事件部分下沉到服务端。
2. 为 twixxel 模块设计回放数据模型
2.1 回放文件的最小字段
回放文件需要包含元信息、帧列表和事件列表三部分。元信息至少包括地图名、录制时长、录制时间和回放数据版本；帧列表按时间排列；事件列表按时间排列。
在开始编码前，先定义 C# 数据结构。这里使用 Unity 的 JsonUtility，它要求类标记为[Serializable]，并且只支持 List、Dictionary 不能直接序列化，所以状态集合使用 List。
[System.Serializable] public class ReplayMeta { public string version = "1.0"; public string mapName; public float duration; public long recordedAt; } [System.Serializable] public class ReplayEntityState { public int id; public float x; public float y; public float z; public float rotX; public float rotY; public float rotZ; public float velX; public float velY; public float velZ; public string action; } [System.Serializable] public class ReplayFrame { public float time; public List<ReplayEntityState> entities = new List<ReplayEntityState>(); } [System.Serializable] public class ReplayEvent { public float time; public string type; public int sourceId; public int targetId; public string data; } [System.Serializable] public class ReplayData { public ReplayMeta meta = new ReplayMeta(); public List<ReplayFrame> frames = new List<ReplayFrame>(); public List<ReplayEvent> events = new List<ReplayEvent>(); }位置和旋转拆成单独的浮点数，是为了避免直接序列化 Unity 的Vector3导致格式混乱。使用action字符串描述动作，虽然比枚举占空间，但方便在不同语言间传递。
2.2 帧采样和事件追加如何配合
录制器每固定时间保存一帧状态，这里称为采样。采样频率决定回放精度，但频率越高文件越大。常见的采样间隔是 0.05 秒，也就是 20Hz，支持大多数移动类角色。
事件不按固定频率走，而是由业务逻辑触发后追加进事件列表。比如角色开火、投掷道具、受到伤害、死亡时，都调用事件接口写入一条记录。
录制窗口通常只保留死亡前 5 秒。为了实现这一点，录制器内部需要维护一个“滑动窗口”：每采样一帧就把超过窗口上限的旧帧删除，同时删除早于窗口开始时间的事件。这样最终保存的文件只包含死亡前一段时间的数据。
2.3 序列化示例：用 JSON 结构描述一局回放
假设场景里只有两个物体，录制了 0.1 秒和 0.2 秒两帧，中间有一次开火事件，最终 JSON 类似下面这样：
{ "meta": { "version": "1.0", "mapName": "training_map", "duration": 0.2, "recordedAt": 1710000000 }, "frames": [ { "time": 0.0, "entities": [ { "id": 1001, "x": 0, "y": 0, "z": 0, "rotX": 0, "rotY": 0, "rotZ": 0, "velX": 0, "velY": 0, "velZ": 0, "action": "idle" } ] }, { "time": 0.1, "entities": [ { "id": 1001, "x": 0.5, "y": 0, "z": 0, "rotX": 0, "rotY": 90, "rotZ": 0, "velX": 5, "velY": 0, "velZ": 0, "action": "move" } ] } ], "events": [ { "time": 0.15, "type": "fire", "sourceId": 1001, "targetId": -1, "data": "{\"weapon\":\"rifle\"}" } ] }这个 JSON 就是 twixxel 模块的核心产物。后续无论做校验、分析还是播放，都围绕这份结构化数据展开。
3. 环境准备和项目结构
3.1 Unity 版本和依赖
示例代码使用 Unity 2021.3 LTS，不需要额外安装第三方插件。序列化使用UnityEngine.JsonUtility，文件读写使用System.IO。如果你的项目已经接入 Newtonsoft.Json，也可以直接替换序列化函数，数据结构和逻辑不需要改变。
如果是 UE4/UE5 项目，只要把 ReplayData 对应为 USTRUCT，把 JSON 序列化换成 UE 的 Json 库，整体设计思路一致。
注意：Unity JsonUtility 无法序列化 Dictionary。如果后续需要多实体查找，先用 List 存储，回放时再转换为字典。
3.2 场景所需的最小物体
为了跑通 Demo，场景中至少需要：
- 一个地面，用来判断角色是否站在场景中。
- 一个玩家角色，挂载移动脚本和 ReplayEntity 组件。
- 一个死亡区域，当玩家进入后触发保存回放。
- 一个播放管理器，负责读取回放文件并实例化回放角色。
示例采用最简化的场景：一个立方体作为地面，一个球体作为玩家，一个红色半透明区域作为死亡区。
3.3 脚本职责和项目结构
把不同职责拆到单独脚本中，方便后续扩展。建议目录结构如下：
Assets/ Scripts/ Replay/ ReplayData.cs ReplayRecorder.cs ReplayEntity.cs ReplayPlayer.cs Demo/ PlayerController.cs DeathZone.cs ReplayLauncher.cs- ReplayData 定义数据结构。
- ReplayRecorder 负责录制状态和事件。
- ReplayEntity 表示一个可录制的物体。
- ReplayPlayer 负责按时间轴播放。
- PlayerController 控制角色移动。
- DeathZone 触发死亡。
- ReplayLauncher 负责切换录制和播放状态。
4. 用最小 Demo 跑通录制和回放
4.1 ReplayData 相关类型的实现
把第 2 节中的类保存到 ReplayData.cs。为了便于播放时查找实体，再补充一个从 ReplayFrame 读取状态列表的辅助方法。
public static class ReplayDataHelper { public static ReplayEntityState FindState(ReplayFrame frame, int entityId) { for (int i = 0; i < frame.entities.Count; i++) { if (frame.entities[i].id == entityId) return frame.entities[i]; } return null; } }这个辅助类会在回放播放器中频繁使用。
4.2 ReplayRecorder 录制器实现
录制器管理采样时间、滑动窗口和文件保存。它不关心具体有哪些对象，只要求对象提供 ReplayEntity 并完成注册。
using System; using System.Collections.Generic; using System.IO; using UnityEngine; public class ReplayRecorder : MonoBehaviour { [Header("采样频率，单位秒")] public float sampleInterval = 0.05f; [Header("死亡回放窗口，单位秒")] public float windowSeconds = 5f; [Header("保存目录")] public string saveDirectory = "Replays"; private ReplayData data; private readonly List<ReplayEntity> trackedEntities = new List<ReplayEntity>(); private bool isRecording; private float startTime; private float nextSampleTime; public void BeginRecording() { data = new ReplayData(); data.meta.mapName = "training_map"; data.meta.recordedAt = DateTimeOffset.UtcNow.ToUnixTimeSeconds(); isRecording = true; startTime = Time.time; nextSampleTime = 0f; trackedEntities.Clear(); } public void RegisterEntity(ReplayEntity entity) { if (!trackedEntities.Contains(entity)) trackedEntities.Add(entity); } public void AddEvent(ReplayEvent replayEvent) { if (!isRecording) return; data.events.Add(replayEvent); } public void StopAndSave() { if (!isRecording) return; isRecording = false; data.meta.duration = Time.time - startTime; TrimData(); SaveToFile(); } private void Update() { if (!isRecording) return; float elapsed = Time.time - startTime; if (elapsed >= nextSampleTime) { CaptureFrame(elapsed); nextSampleTime += sampleInterval; TrimData(); } } private void CaptureFrame(float elapsed) { ReplayFrame frame = new ReplayFrame(); frame.time = elapsed; for (int i = 0; i < trackedEntities.Count; i++) { frame.entities.Add(trackedEntities[i].GetState()); } data.frames.Add(frame); } private void TrimData() { float cutTime = data.meta.duration - windowSeconds; if (cutTime <= 0f) return; for (int i = data.frames.Count - 1; i >= 0; i--) { if (data.frames[i].time < cutTime) data.frames.RemoveAt(i); } for (int i = data.events.Count - 1; i >= 0; i--) { if (data.events[i].time < cutTime) data.events.RemoveAt(i); } } private void SaveToFile() { if (!Directory.Exists(saveDirectory)) Directory.CreateDirectory(saveDirectory); string fileName = $"replay_{DateTime.Now:yyyyMMdd_HHmmss_fff}.json"; string filePath = Path.Combine(saveDirectory, fileName); string json = JsonUtility.ToJson(data, true); File.WriteAllText(filePath, json); Debug.Log($"Replay saved: {filePath}"); } }这里有一个重要的简化和坑：meta.duration在录制过程中是 0，所以TrimData在录制期间不会生效。上面代码中的TrimData调用在录制过程中并不会裁剪，只有当StopAndSave重算duration后才真正裁剪。生产环境中，需要在录制过程中维护一个可用的起始时间戳来裁剪。一个简单改法是保存startTime，在Update中计算当前窗口并裁剪：
private void TrimData() { if (!isRecording) return; float elapsed = Time.time - startTime; float cutTime = elapsed - windowSeconds; if (cutTime <= 0f) return; // 删除帧和事件 }但这样会使meta.duration在文件保存时等于最后一次采样时间，而不是窗口长度，所以保存时仍要重新赋值。为了示例清晰，这里保留一个可运行版本，但注释里需要提醒：滑动窗口应该在录制过程中实时裁剪，而非等到停止时一次性处理。
4.3 ReplayEntity 的录制状态和回放加载
ReplayEntity 挂载到每个需要录制的物体上。它把物体的位置、旋转、速度、动作转成 ReplayEntityState，也支持把 ReplayEntityState 应用回物体。
using UnityEngine; public class ReplayEntity : MonoBehaviour { public int entityId = 1; [Header("动作名称由业务脚本更新")] public string currentAction = "idle"; private Rigidbody cacheRigidbody; private void Awake() { cacheRigidbody = GetComponent<Rigidbody>(); } public ReplayEntityState GetState() { ReplayEntityState state = new ReplayEntityState(); state.id = entityId; Transform t = transform; state.x = t.position.x; state.y = t.position.y; state.z = t.position.z; state.rotX = t.eulerAngles.x; state.rotY = t.eulerAngles.y; state.rotZ = t.eulerAngles.z; if (cacheRigidbody != null) { state.velX = cacheRigidbody.velocity.x; state.velY = cacheRigidbody.velocity.y; state.velZ = cacheRigidbody.velocity.z; } state.action = currentAction; return state; } public void LoadState(ReplayEntityState state) { Transform t = transform; t.position = new Vector3(state.x, state.y, state.z); t.eulerAngles = new Vector3(state.rotX, state.rotY, state.rotZ); if (cacheRigidbody != null) { cacheRigidbody.velocity = new Vector3(state.velX, state.velY, state.velZ); } } }需要注意的是，回放时如果物体有 Rigidbody，应该先把isKinematic设为 true，否则物理引擎会干涉位置，导致回放内容不准确。这一步可以放在 ReplayPlayer 初始化时处理。
4.4 ReplayPlayer 播放器实现
播放器从 ReplayData 中读取帧数据，按时间轴把状态应用到实例化出来的实体上。
using System.Collections.Generic; using UnityEngine; public class ReplayPlayer : MonoBehaviour { public GameObject replayEntityPrefab; public float replaySpeed = 1f; private ReplayData data; private readonly Dictionary<int, ReplayEntity> spawnedEntities = new Dictionary<int, ReplayEntity>(); private float playbackTime; private int frameIndex; private bool isPlaying; public void Play(ReplayData replayData) { Stop(); data = replayData; playbackTime = 0f; frameIndex = 0; isPlaying = true; foreach (ReplayEntityState state in data.frames[0].entities) { SpawnEntity(state); } } public void Stop() { isPlaying = false; foreach (KeyValuePair<int, ReplayEntity> pair in spawnedEntities) { if (pair.Value != null) Destroy(pair.Value.gameObject); } spawnedEntities.Clear(); data = null; } private void SpawnEntity(ReplayEntityState state) { GameObject go = Instantiate(replayEntityPrefab); ReplayEntity entity = go.GetComponent<ReplayEntity>(); entity.entityId = state.id; Rigidbody rb = go.GetComponent<Rigidbody>(); if (rb != null) rb.isKinematic = true; spawnedEntities.Add(state.id, entity); entity.LoadState(state); } private void Update() { if (!isPlaying || data == null) return; playbackTime += Time.deltaTime * replaySpeed; if (playbackTime >= data.meta.duration) { Stop(); return; } while (frameIndex < data.frames.Count - 1 && data.frames[frameIndex + 1].time <= playbackTime) { frameIndex++; } ReplayFrame frame = data.frames[frameIndex]; for (int i = 0; i < frame.entities.Count; i++) { ReplayEntityState state = frame.entities[i]; if (spawnedEntities.TryGetValue(state.id, out ReplayEntity entity)) { entity.LoadState(state); } } } }这个播放器没有做帧间插值，所以如果采样频率是 20Hz，回放时物体可能是跳跃式移动。要获得平滑效果，可以在LoadState之前根据当前playbackTime在上一帧和下一帧之间做线性插值。生产环境建议自行补齐插值逻辑。
4.5 死亡触发和回放流程串起来
玩家控制脚本只负责移动。死亡区检测到玩家进入时，调用录制器的AddEvent记录死亡事件，然后停止录制并保存文件。保存完成后，由 ReplayLauncher 加载回放文件并播放。
using UnityEngine; public class DeathZone : MonoBehaviour { public ReplayRecorder recorder; public ReplayLauncher replayLauncher; private void OnTriggerEnter(Collider other) { if (other.CompareTag("Player")) { ReplayEvent deathEvent = new ReplayEvent { time = Time.time - recorder.recordingStartTime, type = "death", sourceId = other.GetComponent<ReplayEntity>().entityId, targetId = -1, data = "" }; recorder.AddEvent(deathEvent); recorder.StopAndSave(); other.gameObject.SetActive(false); replayLauncher.PlayLatestReplay(); } } }这里引用了recorder.recordingStartTime，需要在 ReplayRecorder 中公开这个字段。录制器已经在BeginRecording里保存startTime，把它改成 public 即可。
ReplayLauncher 负责找到最新生成的 JSON 文件并读取：
using System.IO; using UnityEngine; public class ReplayLauncher : MonoBehaviour { public ReplayRecorder recorder; public ReplayPlayer replayPlayer; public string replayDirectory = "Replays"; public void PlayLatestReplay() { string fullPath = Path.Combine(Application.dataPath, replayDirectory); if (!Directory.Exists(fullPath)) { Debug.LogError("Replay directory not found: " + fullPath); return; } string[] files = Directory.GetFiles(fullPath, "*.json"); if (files.Length == 0) { Debug.LogError("No replay files found."); return; } string latestFile = files[files.Length - 1]; string json = File.ReadAllText(latestFile); ReplayData data = JsonUtility.FromJson<ReplayData>(json); replayPlayer.Play(data); } }为了让replayDirectory指向项目根目录下的 Replays 文件夹，录制器保存路径也要统一。上面 ReplayRecorder 的saveDirectory可以传入Application.dataPath + "/Replays"。
4.6 场景配置步骤
把脚本挂载完成后，按下面的步骤配置：
- 创建空物体
Recorder，挂载ReplayRecorder。 - 创建空物体
Player,子物体为球体，挂载ReplayEntity和PlayerController。 - 为球体添加
Rigidbody并锁定旋转，避免物理影响。 - 创建空物体
DeathZone，添加 Box Collider 并勾选Is Trigger，设置碰撞体大小。 - 创建空物体
ReplayManager，挂载ReplayPlayer和ReplayLauncher，把 Player 预制体拖到replayEntityPrefab。 - 在 DeathZone 中把
Recorder和ReplayManager引用拖好。
运行后先操作角色进入死亡区，控制台会输出保存路径。然后用PlayLatestReplay播放。
由于示例中死亡后 Player 被隐藏，回放播放器会实例化新的球体。为了看到完整回放效果，可以给回放物体设置不同颜色的材质，区分实时角色和回放角色。
5. 关键参数和最容易踩的坑
5.1 三个关键参数的选型思路
录制器的参数会直接影响文件体积、播放效果和内存占用。下面是常见参数参考表：
| 参数 | 常见值 | 作用 | 调大的影响 | 调小的影响 |
|---|---|---|---|---|
| sampleInterval | 0.05s | 状态采样间隔 | 轨迹更平滑，文件更大 | 轨迹粗糙，表现像瞬移 |
| windowSeconds | 5s | 回放窗口时长 | 能看到更早内容，数据量大 | 只能看到死亡前几秒 |
| replaySpeed | 1.0 | 播放倍率 | 回放更快 | 回放更慢，适合调试 |
选择采样频率时，要结合游戏类型。射击游戏建议至少 20Hz，动作游戏最好 30Hz。如果回放中经常出现快速转身，20Hz 可能不够，需要提高到 33Hz。但频率提高会直接放大 JSON 文件体量。
生产环境建议用 30Hz 采样，同时在保存 JSON 前做一次压缩。若使用 MessagePack 等二进制格式，文件体积可以再降低很多。
5.2 四个常见坑的原因和解法
坑一：只录状态、不录事件
现象：回放文件生成成功，但枪口没有火花，技能没有释放效果。
原因：状态帧只保存了位置和动作字符串，没有保存“在这一帧发生了开火”这个瞬时事件。事件只在特定时刻出现，采样几乎是采不到的。
解法：在业务逻辑中遇到开火、投掷、换弹、受伤等瞬时动作时，显式调用AddEvent写入事件，而不是等采样。
坑二：使用欧拉角导致旋转抖动
现象：角色在回放中转身时，旋转角度突然出现 360 度跳变，或者绕轴翻转。
原因：欧拉角在不同角度下有多个等价表达。当采样到 89 度和 -89 度时，数值变化很大，插值结果看起来像乱转。
解法：状态数据中直接存Quaternion的 x、y、z、w 四个分量，回放时使用四元数插值。如果需要 JSON 可读，也可以存四元数的四个浮点数。示例中为了简单使用了欧拉角，生产环境请替换。
坑三：每帧都创建新的 List 和对象
现象：录制一段 10 秒回放后，内存占用飙升，GC 频繁，运行掉帧。
原因：每帧new List<ReplayEntityState>()，每个实体又new ReplayEntityState()，最后全部交给 GC。长时间录制会产生大量垃圾。
解法：使用对象池和可复用缓冲区。在采样时先清空已有 List，再逐个填充对象；或者在帧结束时把对象归还给对象池。学习环境可以先不管，但要意识到这个问题的存在。
坑四：回放时物理系统干扰重建场景
现象：回放刚开始角色正常，几秒后角色滑行、穿墙或直接掉出地图。
原因：回放物体仍然带有 Rigidbody，物理引擎在自动计算碰撞和重力，覆盖了从数据写入的位置。
解法：回放开始时把 Rigidbody 的isKinematic设为 true，并关闭该物体的物理模拟。如果想保留碰撞检测，可以在回放结束后恢复原始状态。
6. 运行验证和结果分析
6.1 检查回放文件内容
录制保存后，打开Replays目录下的 JSON 文件，确认以下内容：
- meta.duration 是否等于从开始录制到触发死亡的时间。
- frames 是否包含多帧数据，且每帧时间递增。
- 最后一帧是否晚于死亡事件。
- events 中是否存在一条 type 为 death 的记录。
如果frames只有一帧，检查角色是否在进入死亡区前就已经触发了录制停止，或者采样间隔没有生效。
6.2 验证回放过程
运行场景，进入死亡区，观察回放播放：
- 球体是否从开始录制的位置移动。
- 球体移动是否连续。
- 是否出现角色先消失、后重新出现的情况。
- 控制台是否有报错日志。
如果球体移动速度明显比实际录制时慢，说明replaySpeed或Time.deltaTime使用不正确。如果球体瞬移，需要提高采样频率或增加帧间插值。
6.3 异常分支验证清单
单纯验证正常流程还不够，至少还要跑通以下异常分支：
| 场景 | 预期行为 | 检查点 |
|---|---|---|
| 玩家出生后立刻死亡 | 保存很小但完整的回放文件 | duration 接近 0，帧数较少 |
| 玩家连续多次死亡 | 每个死亡都生成独立文件 | 文件名时间戳不同，互不覆盖 |
| 回放播放过程中重新开始新回放 | 旧回放停止，新回放完整播放 | 没有残留物体，没有重复实例 |
| 死亡时玩家恰好正在快速旋转 | 回放能还原旋转趋势 | 旋转没有明显跳变 |
| 回放目录不存在 | 自动创建目录，不崩溃 | 首次保存成功后目录存在 |
7. 从 Demo 到生产环境还需要补哪些能力
7.1 数据裁剪、压缩和增量采样
Demo 中一次保存所有帧，在单人场景没问题，但如果一张地图有几十个玩家和大量 NPC，文件会迅速膨胀。生产环境至少要补三件事：
- 录制过程中实时删除超出窗口的旧帧。
- 对坐标字段做定点化处理，保留两位小数或更少，减少 JSON 体积。
- 只记录发生变化的状态，避免每个实体每帧都写入完整位置。
增量采样的思路是：只有当物体位置、旋转或动作与上一帧的差异超过阈值时，才记录新状态。回放时如果某一帧没有某个实体的状态，就沿用上一帧。
7.2 服务端权威回放的落地方式
把回放功能从客户端搬到服务端，不是简单地把 Recorder 脚本放到服务器，而是要把客户端预测和服务器校验的数据统一起来。常见实现路径是：
- 服务端按固定 tick 广播权威位置和事件。
- 客户端持续缓存最近 N tick 的数据。
- 死亡时客户端请求服务端下发权威回放数据，而不是使用本地记录。
- 服务端下发时进行数据裁剪，只下发死亡角色周围必要实体的数据。
这样做的代价是服务端带宽和内存上升，但回放数据可信度大幅提升。反作弊系统可以直接用回放数据识别“子弹穿墙”“自瞄转向异常”等问题。
7.3 回放播放性能优化
回放播放器在生产环境要避免每帧Instantiate和Destroy。最佳实践是预创建一批对象放进对象池，播放时从池中取出，播放结束归还。
回放中每个实体每帧都要应用位置，如果实体数量很多，可以考虑在播放端使用固定步长更新，并把更新频率降到不需要完全等于实时帧率的程度。画面插值则由渲染层处理，与逻辑更新解耦。
7.4 用死亡回放做反作弊取证
死亡回放最重要的生产用途之一，是作为举报投诉的客观依据。
为了能被反作弊系统使用，回放数据中要额外记录这些字段：
- 服务端 tick 序号。
- 实体 ID 对应的玩家标识。
- 重要计算数值，比如命中判定结果、伤害值。
- 校验和或哈希，防止客户端修改本地文件后重新上传。
twixxel 模块后续可以增加一个导出接口，把 JSON 回放上传到存储服务，供运营后台查看和训练检测模型。
7.5 死亡回放开发检查清单
| 检查项 | 完成状态 |
|---|---|
| 回放数据版本号是否写入 meta | 是 |
| 采样频率是否与游戏逻辑频率匹配 | 是 |
| 事件是否覆盖开火、受伤、死亡等关键动作 | 是 |
| 旋转是否使用四元数而不是欧拉角 | 建议改为四元数 |
| 录制期间是否实时裁剪旧数据 | 是 |
| 保存文件是否带时间戳 | 是 |
| 回放物体是否关闭物理模拟 | 是 |
| 是否支持播放中途停止和重新开始 | 是 |
| 是否对文件做完整性校验 | 生产环境需要 |
| 是否记录服务端 tick 或本地时间戳 | 生产环境需要 |
建议把这份清单放到代码仓库的 Replay 模块 README 中，每次改动回放相关代码后都对照检查一遍。
死亡回放看起来是一个“多录几帧、死了播一遍”的小功能，真正做起来涉及状态采样、事件同步、数据裁剪、物理隔离和生产环境可信度等多层问题。twixxel 这套最小实现可以成为团队讨论回放系统的基础起点。下一步最值得做的不是继续堆功能，而是先确定回放数据的消费方：如果只给玩家看，客户端本地录制就够；如果要给客服和反作弊系统用，就必须从第一版开始保留服务端权威数据字段，否则后期迁移成本会很高。
