BitConverter默认按系统字节序工作，小端序下GetBytes(0x12345678)返回{0x78,0x56,0x34,0x12}是正常硬件行为；需用IsLittleEndian判断，跨平台应手动位运算确保大端；ToInt32不校验边界，须前置长度检查。
BitConverter 不是“拿来就能用”的转换工具，它默认按系统字节序工作，直接用于网络协议或跨平台场景大概率出错。
BitConverter.GetBytes 返回的字节顺序为什么和直觉相反
因为 x86/x64 Windows/Linux 默认是小端序（Little-Endian），BitConverter.GetBytes(0x12345678) 返回 {0x78, 0x56, 0x34, 0x12} 是硬件真实行为，不是 bug。你看到的“反序”，其实是最低有效字节（LSB）在最前面。
判断当前环境：直接读 BitConverter.IsLittleEndian，值为 true 表示小端。
若需固定大端（如 HTTP/2、PNG、网络字节序）：
- 别无脑
Array.Reverse—— 它会修改原数组，多线程下不安全 - 推荐手动位运算：
(value >> 24) & 0xFF、(value >> 16) & 0xFF等，明确控制每个字节位置 - 或用
IPAddress.HostToNetworkOrder()处理整数（仅限int/short/long）
BitConverter.ToInt32 越界访问导致崩溃或静默脏数据
ToInt32 完全不检查数组长度和索引边界。传入 new byte[3] 或 startIndex = 100 会直接读托管堆外内存，在 .NET Core/5+ 上可能触发 AccessViolationException，旧版可能静默返回垃圾值。
安全做法：
- 调用前必须验证：
bytes.Length >= startIndex + 4 - 从 socket 或
Stream读取的原始字节，建议先Array.Copy到已知长度缓冲区再处理 - 流式场景优先用
new BinaryReader(stream, isBigEndian: true)—— 它内置长度检查，且支持构造时指定字节序
float/double 转换后 == 比较总是 false 的真相
这不是 BitConverter 的问题。BitConverter.GetBytes(0.1f) 得到的字节完全准确，但 0.1 在 IEEE 754 二进制浮点中本就不能精确表示，存储时必然截断。
正确比较方式：
- 用误差容限：
Math.Abs(a - b) （<code>float）或（<code>double） - 避免混用类型：
ToInt32(bytes, 0)读 8 字节double数组，只会取前 4 字节当int解释，结果无意义 -
ToSingle必须传至少 4 字节，ToDouble至少 8 字节，且起始索引推荐对齐（startIndex % 4 == 0）
Span 和 unsafe 场景下最容易被忽略的风险
BitConverter 的所有 ToXXX 方法都假设内存布局对齐且可信。一旦涉及 stackalloc、Span<byte></byte> 切片或 unmanaged 内存，稍不注意就会触发 AccessViolationException 或静默读脏数据。
这时该换方案：
- 用
BinaryReader（带边界检查和字节序控制） - 或显式
unsafe+fixed控制指针，确保对齐和长度可控 -
BitConverter.AsBytes(12345)返回ReadOnlySpan<byte></byte>是零分配，但依然受字节序影响，不能绕过逻辑校验
