BinaryReader是带默认行为的类型解析器，非底层字节搬运工；ReadInt32()按CPU字节序（通常小端）解析，与文件原始字节顺序可能不一致，需手动读字节+BitConverter处理字节序；ReadString()依赖7-bit长度前缀，仅兼容BinaryWriter.WriteString()，跨语言须改用ReadBytes+UTF8解码；结构体读取须严格按文件真实布局逐字段操作，显式跳过padding；避免用EndOfStreamException作边界判断，应预先校验剩余字节数。
BinaryReader 不是“底层字节搬运工”，它是一层带默认行为的类型解析器——直接拿它读协议文件，十有八九会读错。
ReadInt32() 为什么和十六进制编辑器对不上
你用 ReadInt32() 读出的值和文件里看到的 4 字节顺序不一致，不是 Bug，是预期行为：它按当前 CPU 字节序（通常是小端）解释字节流，不关心文件原始编码意图。
- 如果文件里存的是大端 int32（比如网络协议或 Java 写入），
ReadInt32()会直接错读 - 没有内置参数切换 Endianness；必须手动读字节再转换：
var bytes = reader.ReadBytes(4); var value = BitConverter.ToInt32(bytes, 0); if (!BitConverter.IsLittleEndian) Array.Reverse(bytes); - 浮点数同理：
ReadSingle()假设 IEEE 754 格式，但不校验 NaN/Inf 变体，遇到非法位模式可能抛FormatException
ReadString() 报 EndOfStreamException 的真实原因
ReadString() 不是读“一串非空字节”，而是先读一个变长整数前缀（7-bit 编码长度），再读对应 UTF-8 字节数。失败往往因为前缀本身就不完整，或后续字节不够。
- 它只兼容
BinaryWriter.WriteString()写出的数据格式，和其他语言/工具写入的字符串（如 C++std::string直接 dump）完全不兼容 - 跨语言通信时，绝不能依赖这个方法；改用
ReadBytes(n)+Encoding.UTF8.GetString() - 固定长度字符串（如 32 字节填充空格）必须手动生成字节数组，
ReadString()会把末尾 \0 或空格全当内容读进来
结构体字段读偏移：不是内存布局问题，是你没对齐文件格式
BinaryReader 完全不感知 C# 结构体的 [StructLayout] 或填充字节。它只按你调用顺序消费字节流。文件里怎么排，你就得怎么读。
- 例如字段序列是
short+byte+int，但文件中byte后面实际留了 1 字节 padding（为对齐int），那你必须显式调一次ReadByte()丢弃它 - 别指望
struct Header { [MarshalAs(UnmanagedType.I2)] public short Version; ... }能自动跳过 padding；BinaryReader 不解析 MarshalAs - 协议文档里写的“offset 0x06 处为 Length 字段”，就得用
BaseStream.Position = 6手动跳转，而不是靠字段顺序猜
避免 EndOfStreamException 的唯一可靠方式
别等异常发生再处理——EndOfStreamException 是流程失控的信号，不是边界判断手段。
- 每次读前检查剩余字节数：
if (reader.BaseStream.Length - reader.BaseStream.Position -
PeekChar()对二进制流无效，且会改变内部缓冲状态，禁用 - 流不支持 seek（如
NetworkStream）时，必须依赖协议头声明总长度，或用帧分隔符（如 0xFF 0xFE）做边界识别
最易被忽略的一点：所有 ReadXxx() 方法都不可回滚。一旦读错位置，后续全部错位，且没有任何 API 能帮你“撤回”上一次读取——调试时用十六进制编辑器核对每个字段的起始 offset，比加断点更可靠。
