binaryreader/binarywriter 并非底层操作，而是基于 stream 的封装，不控制字节序、不处理内存对齐、不绕过序列化逻辑；真底层需用 span+memorystream 或直接 filestream 读写。
直接用 BinaryReader 和 BinaryWriter 读写二进制文件是可行的，但必须清楚：它们不是“底层”抽象，而是基于 Stream 的封装，不控制字节序、不处理内存对齐、也不绕过 .NET 的类型序列化逻辑——真要底层操作，得用 Span<byte></byte> + MemoryStream 或直接调用 FileStream.Read/Write。
为什么 BinaryReader 读出来的 int 和你预期的不一样
常见现象：BinaryReader.ReadInt32() 返回值和用十六进制编辑器看到的字节顺序对不上。这是因为 BinaryReader 默认按当前 CPU 的字节序（通常是小端）解析，而你可能误以为它会按文件原始字节流“原样映射”。
- 它不会自动反转字节；如果文件是大端编码的 int32，
ReadInt32()会错读 - 没有内置参数指定 Endianness，必须自己处理：先
ReadBytes(4)，再用BitConverter.ToInt32()配合BitConverter.IsLittleEndian判断是否需要Array.Reverse() - 浮点数同理，
ReadSingle()依赖 IEEE 754 格式且不校验有效性，遇到非规范值（如 NaN 的变体）可能抛FormatException
BinaryWriter.Write(string) 写进去的不只是字符串内容
BinaryWriter.Write(string) 实际写入的是：一个 7-bit 编码的长度前缀（int32，但只用低 7 位表示长度，支持扩展），然后才是 UTF-8 字节。这和你手动 Encoding.UTF8.GetBytes(str) 后写入完全不同。
- 读取时必须用
BinaryReader.ReadString()，否则会把前缀当字符串内容的一部分 - 如果协议要求固定长度字符串（比如 32 字节填充空格），绝不能用这个方法，改用
new byte[32]+Encoding.UTF8.GetBytes()+Array.Copy() - 跨语言通信时尤其危险：C++ 端不会识别这个前缀格式
文件未对齐或结构混杂时，BinaryReader 容易“偏移失步”
典型场景：读一个自定义结构体，字段包括 short、byte、int，但没考虑内存填充。例如：
struct Header {
public short Version; // 2 字节
public byte Flags; // 1 字节
public int Length; // 4 字节 —— 实际在内存中前面可能被补 1 字节对齐
}
这时若连续调用 ReadInt16() → ReadByte() → ReadInt32()，会因实际文件中没留空字节而导致 Length 读错。
-
BinaryReader不感知结构体布局，它只按调用顺序消费字节 - 必须严格按文件真实格式读：如果文件里
Flags后面紧跟 1 字节 padding，就得显式ReadByte()丢弃它 - 更可靠的方式是
ReadBytes(n)一次性读整块，再用Span<byte>.UnsafeRead<t>()</t></byte>（.NET 6+）或Marshal.PtrToStructure()（需StructLayout(LayoutKind.Explicit)）解析
性能敏感场景下，BinaryReader 并非最优选择
每次 ReadXxx() 调用都有方法分派开销，且内部会做边界检查、缓冲区管理。高频小数据读写（如每帧读 1000 个 float）时，吞吐量明显低于直接操作 Span<byte></byte>。
- 用
FileStream.Read(byte[], int, int)一次读大片段，再用Memory<byte>.Slice().Span</byte>配合BinaryPrimitives类（如ReadInt32BigEndian()）解析，速度提升常达 2–3 倍 -
BinaryReader的缓冲区大小默认是 0x1000（4KB），无法设置；若文件随机访问频繁，不如直接关掉缓冲：new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.SequentialScan) - 异步读写不支持
BinaryReader的 async 方法（ReadInt32Async是 .NET 6+ 才有，且仍基于同步基元包装）
真正需要“底层”控制时，BinaryReader 的便利性反而成了干扰项——它隐含的约定（字符串前缀、字节序假设、无填充跳过）比你省下的几行代码更容易埋坑。
