weixin_31315567先说个真实经历。前阵子我们跨平台联调一个服务，A平台打包发过来一个int值，B平台收到的数据怎么看都不对，排查了大半天，最后发现是大小端字节序没转换。当时组里一个刚来的同事很疑惑：int不就是4个字节吗，从内存里读出来应该一样才对？这个问题一问出来，我就知道得专门写一篇东西把“数据在内存中的存储”这件事讲透。
这篇文章不聊虚的，只讲底层最实在的内容：数据在内存里到底长什么样、存放在哪、顺序怎么排、由谁管理、出了问题怎么查。无论你是写C/C++、Java，还是做服务端性能优化、嵌入式开发，甚至只是面试前想补一下基础，这篇文章都能直接拿来用。我会把每个关键点背后的原理、实际踩过的坑和排查手段都写清楚，尽量做到看完就能在项目里落地。
1. 数据在内存中的物理形态：从比特到字节的底层真相
1.1 内存里只有0和1，其它都是“解释方式”
很多人觉得内存里存着“数字”“字符”“字符串”，这个理解本身就有偏差。计算机内存本质上是由数量庞大的存储单元组成的，每个存储单元只能保存一个bit，要么是0要么是1，代表电路里某个电容有没有电荷、某个触发器处于什么状态。8个bit组成一个字节，CPU和操作系统按字节编址，所以你会听到“这个地址存了一个字节”这种说法。
那图片、视频、文字去哪了？它们也被翻译成了0和1，只是长度和排列规则不同。内存本身不区分“这个字节是数字还是字母”，区分这个动作是由程序来做的。同一个字节序列，你用整数类型去读它是一个值，用ASCII去解释它又变成另一个字符。比如十六进制的0x41，以整数看是65，以ASCII看是字母A。这个认知极其重要，很多跨语言、跨平台的数据错乱都源自“解释方式”不一致。
所以在排查内存相关问题时，我习惯先把“原始字节”看一眼，再谈“应该是什么”。用十六进制编辑器或者调试器看一块内存，往往比相信打印出来的日志更接近真相。这就是数据在内存中存储的第一个核心原则：先有比特，后有语义，语义靠程序和类型定义。
1.2 位宽与编码规则：为什么int是4个字节而float是4个字节
不同的数据类型占用的字节数不同，这件事背后是“位宽”与“编码规则”在起作用。
整数的存储相对直观。char占1字节，能表示0到255（无符号）；short通常占2字节；int占4字节；long在64位平台占8字节。位宽越大能表示的数值范围越大，这是用存储空间换表达能力的典型例子。负数在内存里一般用补码表示，补码的好处是加减法可以用同一套电路完成，不需要单独处理符号位。比如-5在4字节int里的二进制是11111111 11111111 11111111 11111011，如果按无符号整数读出来会是一个很大的数，但只要你的类型定义一致，运算就永远是对的。
这里列一个常见整数存储对照表，方便直接查看：
| 类型 | 典型字节数 | 有符号范围 | 无符号范围 |
|---|---|---|---|
| char | 1 | -128 ~ 127 | 0 ~ 255 |
| short | 2 | -32768 ~ 32767 | 0 ~ 65535 |
| int | 4 | -2147483648 ~ 2147483647 | 0 ~ 4294967295 |
| long（64位） | 8 | -9223372036854775808 ~ 9223372036854775807 | 0 ~ 18446744073709551615 |
在实际项目里，这个表能解释很多“奇怪”的现象。比如有人用MySQL建表，看到INT就以为能随便存，结果业务量大了发现溢出；其实MySQL的INT就是4字节，BIGINT才是8字节。又比如Python的int是变长对象，大整数会动态扩展字节数，所以你在Python里算多大都不会溢出，但这不代表内存里它就是固定4字节——恰恰相反，Python整数对象在堆上分配，还要带对象头，比你想的要“胖”得多。
浮点数更有意思。float占4字节，double占8字节，但它们不是按十进制小数存储的，而是按IEEE 754标准拆成符号位、指数位和尾数位三个部分。这导致一个经典问题：0.1用float存，二进制里其实是一个无限循环小数，只能近似表示。所以你在Java、C++、Python里算0.1 + 0.2，结果往往是0.30000000000000004。这不是语言bug，而是浮点在内存里的存储方式决定的。理解这点之后，做金额计算还敢用float的人就少了，大家都会换成整数分、BigDecimal或者十进制定点数。
1.3 大端与小端：多字节数据的“摆放方向”
字节序是数据在内存中存储最容易被忽略、却最容易出大问题的点。一个int占4字节，如果它的值是0x12345678，那么在内存里这4个字节到底按什么顺序放，不同CPU的设计不一样。
大端存储（big-endian）：最高有效字节存在最低地址。也就是内存里依次是0x12、0x34、0x56、0x78，读出来跟书写习惯一致。
小端存储（little-endian）：最低有效字节存在最低地址。内存里依次是0x78、0x56、0x34、0x12，读出来是“反”的。
为什么会有这种差异？早期CPU设计者为了追求某些计算效率，选择了让低字节在低地址的布局，于是x86和ARM主流架构都成了小端。而网络协议为了统一，规定用大端字节序，也就是所谓的网络字节序。这两套规则碰撞在一起，就会出现我开头说的那种情况：A平台按本机小端写了一个int发送，B平台按大端去读，结果数值差了十万八千里。
判断当前机器是大端还是小端，方法很简单，C语言里取一个int变量的首地