C#解析.rofl回放：从二进制拆包到数据管线

简介：LeagueReplayParser 是一个面向 C#/.NET 开发者与《英雄联盟》重播分析爱好者的轻量类库，用于从 .rofl 重播文件中读取基础数据，并借助 League 对象定位客户端安装目录、检查版本信息后启动重播。项目虽已不再积极维护，但源码仍可作为理解重播文件解析流程、客户端路径校验与异常处理的参考。压缩包共 20 个文件，约 505KB，包含 9 个 C# 源码文件、2 个项目工程文件及解决方案文件，另有配置、NuGet 说明文档、依赖 DLL 与示例可执行文件，便于直接查看库结构、示例调用和工程组织方式。已有 710 人学习或下载。读者可从中获得重播解析的核心实现思路、League 对象初始化与 IOException 处理范例，以及按源码、配置和示例分层阅读的完整项目素材，适合做二次开发、课程示例或小型工具原型的参考。

1. 从一堆积灰的 .rofl 说起：这个 C# 库能替你读完那些回放

手头攒了三百多个 .rofl 回放文件的时候，人会很自然地想统计点东西：某套阵容的胜率、打野前十分钟的经济曲线、五分钟内丢了几条龙。可客户端只肯一个一个双击打开，看完关掉再点下一个，一晚上过去进度条才走了二十。这个 C# 写的回放解析库干的就是把这件事从「人肉点开」变成「程序读一遍」——它把 .rofl 这种二进制回放拆成头部、元数据和一条条带时间戳的 packet，解析出的 JSON 里就躺着对局时长、版本号和十名玩家的结算数据，顺带还能把指定文件重新丢回客户端里播放。

它适合两类人：一类是想做数据统计、胜率分析、自动剪辑素材的，拿它当数据入口；另一类是单纯想搞清楚这个二进制格式长什么样的，拿它当解剖刀。需要先打个预防针，这个库已经不再积极维护了，它的价值不在于开箱即用，而在于把「怎么读」这件事写清楚了，剩下的得你自己接。

2. 技术选型与解析链路：魔数头、Blowfish 与 zlib 组成的三段流水线

2.1 为什么是 C# 和 NuGet 这种分发方式

回放文件本质上是一个带索引的压缩加密包，理论上 Python、Go、Rust 都能读。现实里这类工具链最终都落在 .NET 上，原因很朴素：解析完之后往往还要做一件很脏的事——把文件重新交给客户端播放，而桌面端拉起进程、传参、等窗口，C# 的Process.Start和现成的 WPF/WinForms 界面组合起来最省事。做二进制解析时BinaryReader默认按小端读，正好贴合这类格式的字节序约定，不用每读一个uint就手动反转字节序，这一点在写了几百行读取代码之后会格外感激。

分发走的是 NuGet，dotnet add package一行装完，好处是版本可钉、可离线还原、能被 CI 直接吃进去。代价是这个包不再维护了，它的目标框架很可能停在netstandard2.0甚至更老的net45。这不完全是坏事，netstandard2.0意味着从 .NET Framework 4.6.1 一直到现在的新版 .NET 都能引用它；但也意味着你享受不到Span<byte>、Stream.ReadExactly、System.Text.Json源生成器这些新东西，得自己在 fork 里补。

提示：引用旧包时先在 csproj 里确认TargetFramework，工具项目如果用的是新版 .NET，加一个netstandard2.0的兼容引用通常能直接跑，但遇到System.Memory、System.Text.Json之类的传递依赖时要显式补包，否则会在运行期抛FileNotFoundException而不是编译期报错。

2.2 目录结构与三层职责

这个库的组织方式是按「读字节的」「解编码的」「装数据的」分开的，我 fork 之后按自己的习惯整理成下面这样，跟原仓库的差异主要在命名上，职责划分是一致的。

路径	职责	改动频率
ReplayHeader.cs	魔数校验、版本号、七个偏移量字段	极低，格式不变就不动
ReplayReader.cs	对外入口，串起「读头 → 解密 → 解压 → 拆包」	低
Crypto/Blowfish.cs	ECB 模式的分组解密	低，但密钥要跟着版本换
Compression/Zlib.cs	zlib 流的包装，处理长度未知的膨胀	低
ReplayPayload.cs	元数据 JSON + 条目表 + packet 列表	中，格式小改时动这里
ReplayMetadata.cs/GameStats.cs	把 JSON 映射成强类型对象	高，客户端字段常变
Exceptions/InvalidReplayException.cs	统一的「这不是有效回放」异常	低

分层最直接的好处是应对变更。这个格式最常动的地方是元数据里的字段名和密钥，而这两块分别被关在模型层和 Crypto 层里，改起来不会波及头部解析。我见过有人把这三层揉成一个八百行的Parse()，客户端一更新版本，整段代码都没法看，那种血泪经验是真的不想再来一次。

2.3 解析链路：Header → Chunk → Payload → Packet

真正读一个 .rofl 文件，脑子里要有一条固定的流水线。第一步定位头部，四字节魔数对上了才继续，接着读两字节主版本、两字节次版本，从 3.x 开始头部还多出一段 256 字节的签名字段，老版本没有；错过这个分支，后面所有偏移量都会整体错位，读出来的元数据长度是个天文数字。第二步按偏移量把 payload 区整块取出来，判断这个版本要不要解密——早期版本是明文，后期版本用 Blowfish 的 ECB 模式按 8 字节块处理。第三步把解出来的字节丢给 zlib 膨胀，得到一个连续的缓冲区。第四步在这个缓冲区里按长度前缀切三段：元数据 JSON、payload 条目表、packet 序列。

packet 序列这一段是有状态的，每条前面有个标志字节区分普通包和关键帧，关键帧额外带时间戳和校验字段，后面的包体长度才能定下来下一跳的位置。所以解析器不能用「并行分段读」这种讨巧办法，必须老老实实顺序走，一条读完才知道下一条从哪开始。搞明白这一点，后面调试时看到「某一条包长度离谱导致后面全乱」就不会慌了，那通常意味着前面某个字段读错了位。

3. 核心解析拆解：从字节流一路走到 ReplayMetadata

3.1 读头部：魔数校验与七个偏移量字段

头部是整个解析的地基，它的字段顺序记错一位，后面全部连锁崩塌。下面这段是我 fork 后重写的版本，跟原实现思路一致，只是去掉了原版里那些隐式的Position操作，改成显式读取。

public sealed class ReplayHeader { public ushort VersionMajor { get; init; } public ushort VersionMinor { get; init; } public uint HeaderLength { get; init; } public uint FileLength { get; init; } public uint MetadataOffset { get; init; } public uint MetadataLength { get; init; } public uint PayloadHeaderOffset { get; init; } public uint PayloadHeaderLength { get; init; } public uint PayloadOffset { get; init; } } public static ReplayHeader Read(Stream stream) { using var reader = new BinaryReader(stream, Encoding.UTF8, leaveOpen: true); var magic = reader.ReadBytes(4); // 四字节魔数，对不上基本可以判定不是回放文件，或者传输时被截断了 if (magic.Length != 4 || magic[0] != 0x52 || magic[1] != 0x49 || magic[2] != 0x4F || magic[3] != 0x54) throw new InvalidReplayException("魔数不匹配，不是有效的回放文件"); var major = reader.ReadUInt16(); var minor = reader.ReadUInt16(); // 3.x 起头部多了 256 字节签名段，老版本没有；这个分支千万不能省 if (major >= 3) reader.ReadBytes(256); return new ReplayHeader { VersionMajor = major, VersionMinor = minor, HeaderLength = reader.ReadUInt32(), FileLength = reader.ReadUInt32(), MetadataOffset = reader.ReadUInt32(), MetadataLength = reader.ReadUInt32(), PayloadHeaderOffset = reader.ReadUInt32(), PayloadHeaderLength = reader.ReadUInt32(), PayloadOffset = reader.ReadUInt32(), }; }

VersionMajor是所有分支判断的总开关，决定要不要读签名段、要不要解密，务必在构造时第一时间拿到。HeaderLength用于校验——如果它跟当前stream.Position对不上，说明这个版本的头部结构跟你以为的不一样，这时候继续往下读只会得到垃圾，早点抛异常比读出一堆乱码强。FileLength用来做边界检查，防止某些被截断的文件让后续Read越界。MetadataOffset和MetadataLength定位的是明文元数据区，理论上不加密，可以直接读；PayloadOffset才是加密压缩区的起点。用leaveOpen: true是为了让调用方还能继续用同一个流做后续读取，不加的话BinaryReader释放时会把底层流一起关掉，后面就什么也读不了。

3.2 解密与解压：Blowfish 加 zlib 的两步走

这一步最容易翻车，因为两个操作都是「错了不报错，只给你一坨垃圾」的类型。解密用 Blowfish 的 ECB 模式，密钥 16 字节并且跟着客户端大版本走；解压是标准 zlib，但因为源数据长度未知，得靠流式拷贝。

internal static class PayloadCodec { // 密钥必须 16 字节；不同大版本之间会换，别硬编码在主流程里 public static byte[] Decrypt(byte[] cipher, byte[] key) { if (key is null || key.Length != 16) throw new ArgumentException("Blowfish 密钥必须是 16 字节", nameof(key)); if (cipher.Length % 8 != 0) throw new InvalidReplayException("密文长度不是 8 的整数倍，段边界切错了"); using var bf = new Blowfish(key); return bf.DecryptEcb(cipher); // ECB，按 8 字节块处理，末尾不做填充 } public static byte[] Inflate(byte[] deflated, int expectedLength = 0) { using var input = new MemoryStream(deflated, writable: false); using var zlib = new ZLibStream(input, CompressionMode.Decompress); using var output = new MemoryStream(expectedLength > 0 ? expectedLength : 0); zlib.CopyTo(output); // 长度未知，只能流式拷贝 return output.ToArray(); } }

Decrypt里那条 8 的整数倍校验是刻意加的。ECB 按块工作，如果传进来的切片起点偏了一两个字节，长度往往就不再对齐，这是「段边界切错」最灵敏的报警器，比事后对着乱码猜要快得多。Inflate用ZLibStream而不是DeflateStream，因为数据带 zlib 头（前两个字节通常是0x78），用 Deflate 会直接抛「不支持的压缩方法」。expectedLength传 0 表示先让MemoryStream自己扩容，你要是能从头部的长度字段推出来，传进去可以减少几次数组复制，对几百兆的文件有实际意义。

还有一个分支必须显式处理：老版本的 payload 区压根没加密。我的做法是先看前两个字节是不是 zlib 头，是就直接跳过解密，不是再走Decrypt。这比按版本号硬编码判断更稳，因为中间某些小版本的行为并不完全一致。

3.3 payload 拆包：元数据、条目表与 packet 序列

解压出来的缓冲区是一个自描述的结构，按顺序切三段就行。第一段是长度前缀加 UTF-8 的元数据 JSON，第二段是条目表，第三段一直读到末尾的 packet 序列。

public static ReplayPayload ReadPayload(Stream stream, ReplayHeader header, byte[] key) { stream.Seek(header.PayloadOffset, SeekOrigin.Begin); var raw = new byte[header.FileLength - header.PayloadOffset]; ReadFully(stream, raw); // 老框架没有 ReadExactly，自己写循环 var plain = LooksLikeZlib(raw) ? raw : PayloadCodec.Decrypt(raw, key); var buffer = PayloadCodec.Inflate(plain); using var ms = new MemoryStream(buffer, writable: false); using var r = new BinaryReader(ms); // 第一段：元数据 JSON，uint32 长度前缀 + UTF-8 正文 var metaLen = r.ReadUInt32(); var metaJson = Encoding.UTF8.GetString(r.ReadBytes((int)metaLen)); // 第二段：条目表，先给条数，再给每条 (type, length, nextChunkId) var count = r.ReadUInt32(); var entries = new PayloadEntry[count]; for (var i = 0; i < count; i++) entries[i] = new PayloadEntry(r.ReadUInt32(), r.ReadUInt32(), r.ReadUInt32()); // 第三段：packet 序列，从当前位置一直读到缓冲区末尾 var packets = new List<ReplayPacket>(); while (ms.Position < ms.Length) packets.Add(ReadPacket(r)); return new ReplayPayload(metaJson, entries, packets); } private static ReplayPacket ReadPacket(BinaryReader r) { var isKeyFrame = r.ReadByte() == 0x01; // 0x00 普通包，0x01 关键帧 var time = isKeyFrame ? r.ReadSingle() : 0f; // 只有关键帧带时间戳 var id = r.ReadUInt32(); var length = r.ReadUInt32(); return new ReplayPacket(id, time, r.ReadBytes((int)length)); }

PayloadEntry的三元组里，type决定这条数据是发给哪个游戏内通道的，length是这个 chunk 的原始长度，nextChunkId指向链式结构的下一段——这三个字段组合起来才构成完整的重播指令流。ReadPacket里那个isKeyFrame标志是整段的灵魂：关键帧带时间戳，可以从它反推出这一帧对应对局的第几秒，普通包只有 id 和长度。至于关键帧后面到底还跟几个字段，不同版本之间有出入，我一般会留一个switch (header.VersionMajor)的钩子在那儿，客户端一更新就补一个分支，比事后回调崩溃日志省事。

3.4 元数据建模：statsJson 里还套着一层 JSON

元数据本身是 JSON，但里面有个字段叫statsJson，值是「一段 JSON 字符串」——序列化的时候被转义成了字符串，反序列化出来还得再解析一次。这个双层结构是新手最容易卡住的地方，反序列化完看到Stats是 null，会以为是库的问题。

public sealed class ReplayMetadata { [JsonPropertyName("gameLength")] public int GameLength { get; init; } [JsonPropertyName("gameVersion")] public string GameVersion { get; init; } = ""; [JsonPropertyName("statsJson")] public string StatsJson { get; init; } = ""; // 二次反序列化的结果单独放，不参与主 JSON 的映射 public GameStats? Stats { get; private set; } public void Materialize() { if (string.IsNullOrWhiteSpace(StatsJson)) return; Stats = JsonSerializer.Deserialize<GameStats>(StatsJson); } } public sealed class GameStats { [JsonPropertyName("gameDuration")] public int GameDuration { get; init; } [JsonPropertyName("players")] public List<PlayerStats> Players { get; init; } = new(); } public sealed class PlayerStats { [JsonPropertyName("summonerName")] public string Name { get; init; } = ""; [JsonPropertyName("teamId")] public int Team { get; init; } [JsonPropertyName("kills")] public int Kills { get; init; } [JsonPropertyName("deaths")] public int Deaths { get; init; } [JsonPropertyName("assists")] public int Assists { get; init; } }

Materialize()做成显式方法而不是构造函数里自动执行，是因为不是所有场景都要吃 stats——只做快速探测时（比如大批量文件按版本号分类）跳过这一步能省掉大量对象分配。JsonPropertyName一定要显式标上，别指望默认的驼峰匹配规则，元数据里字段的命名风格并不统一。GameDuration和头部的关键帧时间戳可以互相校验，这两个数差超过一秒，基本可以断定 packet 序列在某个位置读漏了。

4. 跑起来：控制台入口、样本回归与客户端拉起

4.1 环境准备与工程创建

先把 SDK 和一个样本文件准备好。样本最好选一个你确定知道对局时长的文件，因为后面要用它当标尺。这个库不再维护，所以引用时要留意目标框架的兼容性，别一上来就在新项目里硬顶。

dotnet --list-sdks # 确认至少有一个可用的 SDK mkdir replay-probe && cd replay-probe dotnet new console -f net8.0 # 包 Id 以 NuGet 上搜到的为准，别照抄博客里的拼写 dotnet add package <解析库的包 Id>

如果还原时报「包不兼容当前目标框架」，不要急着换 SDK 版本，先看这个包支持的最低框架是什么。多数情况下加<NoWarn>NU1701</NoWarn>忽略兼容性警告就能跑起来，因为netstandard2.0的程序集在运行时是可以被新框架加载的。真正需要担心的是它依赖的System.Text.Json之类传递包版本太老，跟你的项目打架，那时候在 csproj 里显式钉一个更高版本就行。

4.2 一个最小可用的调用示例

把下面这段塞进Program.cs，一个能跑通的探针就有了。

// args[0] = .rofl 文件路径 using var fs = File.OpenRead(args[0]); var header = ReplayHeader.Read(fs); var key = KeyRing.ForVersion(header.VersionMajor); // 密钥按版本取 var payload = ReplayReader.ReadPayload(fs, header, key); var meta = payload.Metadata; meta.Materialize(); Console.WriteLine($"{header.VersionMajor}.{header.VersionMinor} | " + $"{meta.GameLength / 60.0:F1} 分钟 | " + $"{meta.Stats?.Players.Count ?? 0} 名玩家 | " + $"{payload.Packets.Count} 个包");

这段代码的每一步都对应前面拆过的环节：ReplayHeader.Read只读文件头那一小段，KeyRing.ForVersion是密钥管理，ReadPayload一口气把加密压缩区解完并拆包，Materialize才真正去解析那层嵌套的 JSON。输出里四个字段各有用途：版本号用来判断这个文件是哪套解析规则，时长用来跟 packet 里的关键帧对账，玩家数验证 stats 有没有解析成功，包总数则是判断有没有中途断掉的粗指标。

参数	含义	常见取值与注意点
VersionMajor	主版本号，决定分支	2 以下一般不加密，3 以上带签名段
PayloadOffset	加密区起点	必须用头部读出来的值，不能按固定长度硬算
key	16 字节 Blowfish 密钥	跟客户端大版本绑定，取错会得到乱码而非报错
GameLength	对局时长（秒）	与最后一个关键帧时间戳做交叉校验

4.3 拉起客户端重播

解析完之后要重播，本质上就是把文件路径当成启动参数丢给客户端进程。这件事看着简单，坑却不少，主要是路径转义和工作目录。

public static void LaunchClient(string clientExe, string roflPath) { if (!File.Exists(clientExe)) throw new FileNotFoundException("客户端可执行文件不存在", clientExe); if (!File.Exists(roflPath)) throw new FileNotFoundException("回放文件不存在", roflPath); var psi = new ProcessStartInfo(clientExe) { UseShellExecute = false, // 路径里有空格时必须自己带引号，UseShellExecute=false 不会帮你转义 Arguments = $"\"{roflPath}\"", WorkingDirectory = Path.GetDirectoryName(clientExe)! }; Process.Start(psi); }

UseShellExecute = false是为了拿到Process对象做后续的退出码判断，但如果路径里带空格而你没加引号，参数会被拆成两段，客户端只会收到半截路径然后静默失败——这个症状特别像「客户端坏了」，实际是字符串拼接的问题。WorkingDirectory一定要设成客户端所在目录，否则部分资源加载会失败。另外，如果客户端已经在运行，新的启动请求通常会被转交给已有实例，这是预期行为，不用惊慌；但版本不匹配的文件会被直接拒绝，这时候只能换一个对得上版本的客户端。

4.4 用样本集做一轮回归

单文件跑通之后，立刻做一遍批量回归。这一步的意义是提前发现版本分支的问题，别等处理线上几百个文件时才发现某一批全是乱码。

# 把所有样本跑一遍，只保留摘要行，异常单独抓出来 for f in samples/*.rofl; do echo "== $f" dotnet run --no-build -- "$f" 2>&1 | head -n 3 done

跑完对着输出扫一眼：版本号分布是不是集中在两三个值上，有没有哪个文件的玩家数是 0，包总数有没有明显偏小的。包数偏小通常意味着解析在某个位置停住了，而while (ms.Position < ms.Length)这个循环不会报错，它只会安静地少读几条。所以回归里真正有价值的断言不是「没抛异常」，而是「包数落在合理区间内」和「对局时长跟关键帧时间对得上」。

5. 避坑记录：五个把回放读成乱码或空对象的现场

5.1 魔数对得上，读元数据却抛 EndOfStream

现象：头部四个字节校验通过，版本号也像模像样，但一读元数据长度就抛EndOfStreamException，或者读出来是个几千万的天文数字，紧接着数组分配直接OutOfMemory。原因几乎可以锁定在版本分支上——3.x 开始头部多了一段 256 字节签名字段，代码里没判断版本就往下读，后面的七个偏移量全部错位。解决办法是把HeaderLength当成断言用：读完头部之后比对stream.Position跟它是否一致，不一致就别继续了。我后来养成的习惯是把头部所有字段以十六进制打一行日志，版本一换立刻能看出是哪个字段开始漂。

5.2 解密出来还是乱码，但程序不报错

现象：Decrypt顺利返回，Inflate却抛「不支持的压缩方法」，或者解出来一堆零字节。原因有两个方向：一是密钥跟客户端版本不配套，ECB 解密是幂等的，密钥错了也照样吐出一堆长度正确的垃圾；二是这个版本的 payload 压根没加密，你却硬走了一遍Decrypt。判断方法很简单，看原始字节的前两个字节是不是0x78，是就说明本来就是 zlib 流，跳过解密。密钥这块更麻烦，它跟着客户端大版本走，客户端一更新就可能换，所以别把密钥硬编码在主流程里，抽成一个按版本查表的类，改的时候只动一个文件。

5.3 解压报「条目使用了不支持的压缩方法」

现象：ZLibStream读到一半抛InvalidDataException。原因多半是切片的起止位置算错了，把 header 区或者条目表的一部分也喂给了 zlib。我踩过一次，是因为用了header.MetadataOffset + header.MetadataLength去推算 payload 起点，看起来合理，实际上中间还有一段对齐填充。正确做法是直接用PayloadOffset和FileLength两个字段切，不要去推算中间区域。另一个常见原因是把文件尾部那段不属于 payload 的附加数据也一起读了进来，切的时候用长度字段卡死，别用「读到文件末尾」。

5.4 stats 解析出来全是 null，玩家数一直是 0

现象：meta.GameLength有值，meta.Stats却不是 null 但里面每个字段都是默认值，Players空着。原因是那个双层 JSON——statsJson字段的值是一段被转义过的字符串，直接反序列化到GameStats当然对不上。必须先取字符串再Deserialize一次。还有一种情况是字段名大小写不匹配，元数据里不全是驼峰，混着下划线和首字母大写，所以每个属性都老老实实标JsonPropertyName，别偷懒靠默认规则。调这块的时候，把StatsJson原样写到一个.json文件里用编辑器打开看，比在调试器里读转义字符串快十倍。

5.5 客户端启动后没反应或者秒退

现象：Process.Start返回了非 null 的Process对象，但窗口一闪而过，或者干脆什么都不发生。按概率排：路径带空格没加引号，参数被拆成两段；WorkingDirectory没设，客户端在自己的目录里找不到资源；客户端已经在运行，请求被转交但版本不匹配被拒绝；文件来自不同补丁，客户端直接判定不兼容。排查顺序建议从最简单的那条开始——先把命令行参数打印出来，复制到资源管理器地址栏里手敲一遍，能起来就说明是转义问题，起不来再往版本兼容上想。这个环节没有后悔药，客户端不给你任何错误信息，只能靠二分法缩小范围。

6. 二次开发：把解析层改造成自己的数据管线

拿这个库做二次开发，第一步不是加功能，是把它从「一次性读完一个文件」改成「能流式喂数据」。原来的入口是ReadPayload(Stream, header, key)，一次性把 payload 全解到内存里，几百个文件批量处理时内存峰值会很难看。我的做法是把packets那个List<ReplayPacket>换成IEnumerable<ReplayPacket>加yield return，调用方想只看前两百个包做快速探测时，后面的解压工作根本不会发生。这个改动很小，但对「先扫一遍所有文件判断版本分布」这种场景是数量级的差别。

再往上就是抽接口。把「回放来源」抽象成IReplaySource，本地文件、内存流、从对象存储拉下来的临时文件都实现它，解析层只认接口。这一层抽象带来的直接好处是测试变简单了：不用准备真实文件，构造一个MemoryStream塞几个合成字节就能验头部解析，不受真实文件体积拖累。

public interface IReplaySource { Stream OpenRead(); // 每次调用返回一个可独立读取的流 string Name { get; } } // 只解析到元数据，packet 惰性产出，适合大批量统计 public static IEnumerable<ReplayPacket> EnumeratePackets( IReplaySource source, byte[] key, CancellationToken ct = default) { using var stream = source.OpenRead(); var header = ReplayHeader.Read(stream); foreach (var packet in ReplayReader.ReadPayloadStreaming(stream, header, key)) { ct.ThrowIfCancellationRequested(); yield return packet; } }

OpenRead()每次返回新流而不是复用同一个，是为了让多个消费方互不干扰——批量任务里经常出现「先算哈希再解析」两条流水线同时吃同一个文件的情况，复用流会在Seek上打架。CancellationToken那个检查点放在循环里，作用是在用户点取消时立刻退出，而不是等整个文件解完。

验证这套改造是否正确的办法，我一直用同一招：拿一个已知时长的样本，把最后一个关键帧的时间戳打出来，跟GameLength对账，差值超过一秒就说明漏包了。再看包总数是否落在往常数百到数千的区间里。这两个数都对得上，基本可以确信解析链路没被改坏。要更进一步，可以把玩家列表按队伍分组打印，看是不是正好两支队伍、人数相等——这一步能抓出「元数据读了一半就停」的情况，因为Players数组是分段填充的。

最后一个技巧是关于性能的：解压出来的缓冲区用ArrayPool<byte>.Shared租而不是每次new，批量处理几千个文件时 GC 压力会明显下降。租来的数组记得在finally里还回去，这个我吃过一次亏——某次忘了还，跑了两万个文件之后进程直接被内存吃掉。

从那以后我每次接一种新的二进制格式，都会先做一件事：把头部所有字段按十六进制打一行日志，然后拿一个最老的样本和一个最新的样本各跑一遍，把两行日志并排放着看。结构差异一眼就能看出来，比读文档靠谱得多，因为这个格式没有文档可读。希望这个思路帮到你。

本文还有配套的精品资源，点击获取