bitconverter默认按系统字节序工作，小端序下getbytes(0x12345678)返回{0x78,0x56,0x34,0x12}是正常现象；需用bitconverter.islittleendian判断；跨平台应手动位运算确保大端；toint32不校验边界，须前置长度检查。
BitConverter 不是“拿来就能用”的转换工具，它默认按系统字节序工作，直接用于网络协议或跨平台场景大概率出错。
为什么 BitConverter.GetBytes(0x12345678) 返回 {0x78, 0x56, 0x34, 0x12}？
这不是 bug，是小端序（Little-Endian）的正常表现：x86/x64 Windows/Linux 默认把最低有效字节放在最前面。你看到的 “反直觉” 字节排列，恰恰是硬件真实读写顺序。
- 判断当前系统是否小端：直接读
BitConverter.IsLittleEndian，值为true表示小端 - 若需固定大端（如 HTTP/2 帧头、PNG 文件格式、网络字节序），不能只靠
Array.Reverse—— 它会修改原数组，多线程下不安全 - 更稳妥的做法是手动位运算构造：
(value >> 24) & 0xFF、(value >> 16) & 0xFF等，明确控制每个字节位置
ToInt32 报 InvalidProgramException 或返回奇怪数字？
根本原因不是数据错，而是越界读内存：BitConverter.ToInt32 完全不检查数组长度和索引边界，传入 new byte[3] 或 startIndex = 100 会直接访问托管堆外地址。
- 必须前置校验：
if (bytes.Length - 从
Stream或 socket 读取的原始字节，建议先Array.Copy到已知长度缓冲区再调用，避免切片引用失控 - 替代方案更省心：
new BinaryReader(stream, Encoding.UTF8, leaveOpen: false).ReadInt32()—— 它内置长度检查，且支持构造时指定isBigEndian: true
float/double 转换后 == 比较总是 false？
这不是 BitConverter 的问题，而是 IEEE 754 浮点数本质限制：0.1f 在二进制中无限循环，存储时必然截断。转换过程本身字节完全准确。
- 比较应改用误差容限：
Math.Abs(a - b) （<code>float）或1e-10（double） - 混用类型极易崩溃：用
ToInt32(bytes, 0)读 8 字节double数组，只会取前 4 字节当 int 解释，结果无意义 - 务必匹配长度：
ToSingle只读 4 字节，ToDouble必须传至少 8 字节，且起始索引要对齐（startIndex % 4 == 0推荐）
真正容易被忽略的是：BitConverter 的所有 ToXXX 方法都假设内存布局对齐且可信。一旦涉及 unmanaged 内存、stackalloc 或 SpanAccessViolationException 或静默读脏数据——这时候该换 BinaryReader 或显式 unsafe + fixed 控制了。
