BitConverter默认小端序导致字节顺序与直观预期相反；ToInt32越界会引发内存访问异常；float/double精度丢失源于IEEE 754限制，并非BitConverter缺陷。
BitConverter.GetBytes 为什么返回的字节顺序和你预期不一样
因为 BitConverter 默认使用当前系统的字节序（通常是小端序），GetBytes(int) 返回的是低位字节在前的 4 字节数组。比如 BitConverter.GetBytes(0x12345678) 在 x64 Windows 上结果是 {0x78, 0x56, 0x34, 0x12}，不是直观的“从左到右”排列。
如果你需要固定大端序（如网络传输、跨平台协议），不能直接依赖 BitConverter 的默认行为：
- 先用
BitConverter.GetBytes获取原始字节数组 - 再调用
Array.Reverse（仅当BitConverter.IsLittleEndian == true时） - 或手动拼接：用
(value >> 24) & 0xFF等位运算构造大端字节数组（更可控，无副作用）
BitConverter.ToInt32 读错位置导致 InvalidProgramException 或值异常
常见错误是传入的 byte[] 长度不足 4 字节，或起始索引 startIndex 越界——ToInt32 不做长度校验，越界会直接读取托管堆外内存，可能触发 AccessViolationException（.NET Core/5+）或静默读脏数据。
安全做法：
- 始终检查
bytes.Length >= startIndex + 4 - 避免从用户输入、网络流等不可信源直接切片后调用，应先
Array.Copy到已知长度缓冲区 - 若处理流式数据，优先用
BinaryReader.ReadInt32()，它内置边界检查和 Endianness 控制（需配合BinaryReader构造时指定isBigEndian）
float/double 转换时精度丢失不是 BitConverter 的问题
BitConverter.GetBytes(0.1f) 得到的字节完全正确，但 0.1 在二进制浮点中本就不能精确表示——这是 IEEE 754 标准限制，和 BitConverter 无关。真正容易被忽略的是：
-
Single和Double的字节长度不同（4 vs 8），混用ToInt32/ToInt64会直接崩溃 - 用
BitConverter.ToSingle(bytes, 0)读 8 字节数组前 4 字节，结果未定义（实际是读前 4 字节按 float 解释，但剩余字节被忽略） - 比较转换前后值是否相等，应避免
==，改用Math.Abs(a - b)
想绕过 BitConverter 直接操作内存？小心 Span<byte> 和 Unsafe
.NET Core 2.1+ 提供了更底层、零分配的方式：
-
var bytes = BitConverter.AsBytes(12345)返回ReadOnlySpan<byte></byte>，不分配数组 -
Unsafe.AsRef<int>(bytes.GetPinnableReference())可直接把字节数组首地址转为int引用（需unsafe上下文，且确保对齐） - 但这些跳过所有安全性检查：如果
bytes是非对齐栈内存或长度不足，运行时可能崩溃，调试难度远高于BitConverter
除非你在高频循环里处理百万级数值且已确认内存布局稳定，否则别为了“底层感”过早替换 BitConverter。
