printf()输出是否受字节序影响？小端模式下代码输出结果与预期不符的原因探究

咱们一步步拆解你的问题，先搞清楚为什么输出是0x00008342，再聊printf的字节序影响。

一、为什么输出和预期不符？ #

先回顾你的代码和内存存储情况：

• 你定义了unsigned long long x = 0x0000000000008342，在小端模式下，多字节数据的最低有效字节会存在最低内存地址，所以x的内存布局是：

  0x00: 0x42  // x的最低有效字节
  0x01: 0x83
  0x02: 0x00
  0x03: 0x00
  0x04: 0x00
  0x05: 0x00
  0x06: 0x00
  0x07: 0x00
  

• 你把x的指针强制转换成unsigned int* y_p，这时候y_p指向的是x的低4字节（地址0x00到0x03）。
• 关键误区在这里：小端模式不仅管存储，还管多字节数据的读取逻辑。当你用unsigned int类型读取这4个字节时，CPU会把低地址的字节当作数值的最低位（LSB），高地址的字节当作最高位（MSB）。

具体计算一下：

• 地址0x00的0x42 → 对应数值的2^0位，即0x42
• 地址0x01的0x83 → 对应数值的2^8位，即0x83 << 8 = 0x8300
• 地址0x02、0x03的0x00对数值无影响

把这些加起来就是0x8300 + 0x42 = 0x8342，也就是你看到的0x00008342。你预期的0x00004283是直接按内存地址顺序拼接字节，但这是错误的——多字节类型的读取必须遵循字节序规则，不是简单的地址顺序拼接。

二、printf()的输出受字节序影响吗？ #

答案是完全不会。

原因很直白：当你把unsigned int y传给printf时，y已经是CPU解析完成的数值（比如这里的0x00008342），这个数值在CPU内部是统一的抽象表示，和它在内存里的存储字节顺序毫无关系。printf只负责把这个抽象数值转换成十六进制字符串输出，它只关心数值本身，不关心数值的存储方式。

举个例子：不管你的系统是小端还是大端，只要y的实际值是0x8342，printf("%#.8x", y)都会输出0x00008342——输出的是数值的标准十六进制表示，和字节序没有关联。

内容的提问来源于stack exchange，提问作者Milan