整数和浮点数在内存中存储，这件事我写业务代码的头两年完全没当回事。直到某次数据平台联调，客户端上报 149.99，服务端算完返回 149.99000000000002，两边查验代码都没毛病，最后定位到是计算路径里混用了 float 和 double，精度在第一步就丢了。那次之后我意识到，凡是涉及数值的 Bug，最后都要回到一个老问题上：数字在机器的内存里到底是怎么被摆布的。这篇就把整数和浮点数的内存存储规则彻底说透，把原码补码、字节序、IEEE 754、精度损失这些概念的来龙去脉讲清楚，顺便把我在工作中踩过的坑和排查手法一起写出来。适合刚入门的新人，也适合写了很多年代码但一直没深究过底层表示的老手。
1. 一次联调事故：两边代码都没错，数值却对不上
1.1 现象描述
那次事故简单说就是：客户端把金额 149.99 以文本形式传上来，服务端收到后转成 float 参与计算，再以 double 返回给前端展示。前端看到的数值尾巴多了一个 00000000000002。两边各自单元测试都通过，代码逻辑也没有"错误"，纯粹是数值在三十二位浮点里被截断，再提升到六十四位时，截断造成的误差被"放大"展示了出来。
这个案例的核心不是计算逻辑，而是存储环节。数字从十进制文本进入二进制内存的那一刻，就已经不是你以为的那个数了。
类似的情况我相信不少人都遇到过：数据库里存的好好的小数，读出来变成 34.56999999999999；两个浮点数比较死活不相等；某个大整数过了一遍函数就"变"了。这些问题如果只在业务层找 bug，往往找不到。真正的源头在内存表示层。
1.2 先建立一张基本盘表格
在展开细节之前，先把常见数值类型的内存位宽和特性列清楚：
| 类型 | 总位数 | 存储规则 | 表示范围/有效精度 |
|---|---|---|---|
| int（32位） | 32 | 补码 | -2147483648 ~ 2147483647 |
| long long（64位） | 64 | 补码 | -9223372036854775808 ~ 9223372036854775807 |
| float | 32 | IEEE 754 | 约 7 位有效十进制数字 |
| double | 64 | IEEE 754 | 约 15~16 位有效十进制数字 |
这张表值得记住的关键不是数字本身，而是"整数在范围内是精确的，浮点数只是近似值"这件事。浮点数和整数最本质的差别就在这里：整数用固定位数直接编码数值，浮点数用"符号 + 指数 + 尾数"的方式编码，天然牺牲精度换取范围。
1.3 边界处最容易暴雷
从我的经验看，数值问题基本都发生在"边界"上。所谓边界包括：不同语言之间传参、二进制文件读写、网络协议字段解析、数据库存取、JSON 序列化。这些场景下，数据要跨越存储格式的"翻译区"，一旦两端对存储规则的理解不一致，就出问题。理解了内存存储规则之后，你再遇到这类问题，第一反应应该是"先看看这两端对数字的假设是否一致"，而不是急着改业务逻辑。
而整数的补码表示和浮点数的 IEEE 754 表示，就是理解这些问题的两把钥匙。下面的章节逐一往下拆。
2. 整数在内存里的真面目：补码为什么非要绕这么一圈
2.1 原码、反码、补码的三层演进
先看最直觉的方案：直接用一个符号位加绝对值，这叫原码。8 位里 +5 是 00000101，-5 是 10000101。看起来很好懂，但硬件实现加法时麻烦就来了：如果两个数符号不同，不能直接把数值位相加，得先比较绝对值大小，再决定谁减谁，最后还得处理符号。这套逻辑在电路里要多好几层判断。
于是有了反码：负数把原码的数值位全部取反，-5 变成 11111010。但反码有个尴尬的地方：0 有两种表示，00000000 和 11111111，硬件判断"是不是零"还得做一次特判。
最终方案是补码：负数等于反码加一，-5 变成 11111011。这一下子把两件事全解决了。先看加法，+5 的补码 00000101 加上 -5 的补码 11111011，结果是 1 00000000，最高位的进位直接被丢弃，剩下 00000000，正好是 0。也就是说，CPU 不需要知道操作数是不是负数，用一个加法器就能同时处理正负数的加减法。
2.2 补码的广度和它的不对称范围
既然负数是"反码加一"，那 -128 在 8 位里怎么表示？原码的最小值是 -127，反码也是 -127，但补码把 10000000 这个原本在反码里表示"负零"的位型复用成了 -128。所以 8 位补码的范围是 -128 到 127，比"对称"的原码/反码多出一个负数。这也是为什么面试里总有人问"为什么 int 的最小值绝对值比最大值大 1"——答案就藏在这套位型的逻辑里。
这种不对称在实际代码里经常产生"看似诡异"的现象。比如：
#include <stdio.h> int main(void) { char c = 127; c = c + 1; printf("%d\n", c); // 常见的输出是 -128 return 0; }127 的补码是 01111111，加 1 变成 10000000，按有符号解读就是 -128。计算器没"出错"，而是位型本身在以补码规则被解释。注意这里 C 语言对有符号溢出的处理其实属于实现定义行为，我拿它演示的是位型变化本身，实际工程里不要依赖这种写法。
2.3 有符号和无符号混用的隐式转换坑
比溢出更阴险的是有符号和无符号混用时的隐式转换。C 语言的一个经典例子：
unsigned int a = 1; int b = -1; if (a > b) { printf("a > b\n"); } else { printf("a <= b\n"); }直觉上 a 大于 b 应该输出 a > b，实际却走到 else。原因是在比较时，b 被转换成了 unsigned int，-1 变成 4294967295，所以 1 大于 4294967295 不成立。要理解这个转换，就得知道 -1 的补码是 0xFFFFFFFF——它"按无符号读"就是 4294967295。
所以我在写跨语言或底层代码时，会定一条硬规矩：能不用无符号就不用无符号；必须用时，把关卡设在接口层，用显式转换把关，而不是依赖隐式规则。
3. 字节序陷阱：同一串十六进制在不同机器上可能"倒着念"
3.1 大端小端的内存布局
补码解决的是"每一位代表什么"，字节序解决的是"多个字节在内存里的先后顺序"。假设一个 32 位整数 0x12345678，在小端机器上，最低地址存的是最低字节 0x78，然后是 0x56、0x34、0x12；大端机器则相反，低地址先存最高字节 0x12。
这个概念看起来只是"顺序不同"，但一旦二进制数据跨机器传递，就会变成"读出来的数完全不对"的灾难。比如一个 uint16_t 值 0x1234（十进制 4660），在小端机器里写成文件，字节顺序是 34 12；换到大端机器按大端规则读取，会把 0x3412 解读成 13330。数值翻了近三倍，而且没有任何逻辑上的解释。
3.2 我在一个二进制文件读写模块里踩过的坑
某次接手某跨平台模块，文件头有 uint32 魔数。在开发机上生成的文件，拿到另一台服务器解析，程序直接报"文件格式错误"。一开始怀疑压缩算法或字段顺序，折腾了半天。后来把文件前 8 个字节用十六进制编辑器看了一眼，发现同样一个魔数，两边读出来的字节序完全不同。问题根源是写入端没有做字节序统一，直接按本机字节序写盘，读取端又按本机字节序解析。两台机器字节序不一致，文件就废了。
处理方式其实很简单：
- 文件格式或网络协议里，明确所有多字节字段都使用大端（网络字节序）；
- 写入时调用 htonl/htons 或等效函数转换；
- 读取时调用 ntohl/ntohs 还原成本机字节序；
- 如果手写编码，就用移位拼装，而不是取地址直接搬。
例如手写打包一个 uint32 大端：
uint32_t v = 0x12345678; unsigned char buf[4]; buf[0] = (v >> 24) & 0xFF; buf[1] = (v >> 16) & 0xFF; buf[2] = (v >> 8) & 0xFF; buf[3] = v & 0xFF;这样无论在什么机器上，输出字节都是 12 34 56 78。
3.3 判断字节序的实操方法
判断当前机器字节序最简单的方式，是在调试器里看一个已知整数的内存字节，或者直接打印指针指向的 char：
uint32_t x = 0x12345678; unsigned char *p = (unsigned char *)&x; printf("%02x %02x %02x %02x\n", p[0], p[1], p[2], p[3]);小端输出是 78 56 34 12，大端输出是 12 34 56 78。注意我这里用了指针强转，只是为了演示；实际工程里判断字节序，我更喜欢用联合体或者直接依赖协议的固定字节序转换函数，避免未定义行为。
4. 浮点数的三段式结构：符号、指数、尾数如何各司其职
4.1 IEEE 754 的字段划分
浮点数在国际上是 IEEE 754 标准统一规定的，不是某家公司私有。32 位 float 分成三段：1 位符号、8 位指数、23 位尾数；64 位 double 是 1 位符号、11 位指数、52 位尾数。
它的核心思想是科学计数法的二进制版：value = (-1)^sign × 1.fraction × 2^(exponent_field - bias)。其中指数是"移码"存储，float 的 bias 是 127，double 是 1023。之所以叫"移码"，是因为指数既可能有正有负，直接用补码比较大小反而不方便，把真实指数加上一个偏移量之后，存进字段的数值越大代表的指数越大，硬件比较就变得简单。
尾数部分还有个隐藏技巧：规格化数的整数位必然是 1，所以标准不存这一位，省出一个 bit 的有效精度。也就是说 float 虽然尾数位是 23 位，实际精度是 24 位有效二进制位；double 是 53 位。
4.2 几个手工拆解的例子
看 1.0f。它等于 1.0 × 2^0，符号 0，指数字段 127，尾数字段全 0，整体位型是 0x3F800000。
看 -3.75。先用二进制表示整数部分和小数部分：3 是 11，0.75 是 0.11，合起来 11.11，科学计数法写成 1.111 × 2^1。符号位 1，真实指数 1 加 bias 127 得 128，尾数部分 111 后面补零。位型是 1 10000000 11100000000000000000000，十六进制 0xC0700000。
再看 0.1。十进制 0.1 转换成二进制，是个无限循环小数：0.00011001100110011001100…… 你永远没法用有限的 bit 精确写出来。所以"0.1 在内存里不等于 0.1"，不是 bug，是规则使然。float 版的 0.1 实际存储值是 0x3DCCCCCD，大约等于 0.10000000149011612。
4.3 特殊值：NaN、无穷和正负零都靠指数位特判
IEEE 754 里指数位全 0 和全 1 有特殊含义：
| 指数位 | 尾数位 | 含义 |
|---|---|---|
| 全 0 | 全 0 | ±0（符号位决定正负零） |
| 全 0 | 非 0 | 次正规数（极小数值，精度逐步丢失） |
| 全 1 | 全 0 | ±无穷（如除法溢出、超过最大范围） |
| 全 1 | 非 0 | NaN（如 0/0、负数开方） |
这个表值得背下来，因为 NaN 有一个反直觉的特性：NaN 和任何值都不相等，包括它自己。我在做数值校验时遇到过的问题是，一个 NaN 参与运算后静默传播，最后把结果也变成 NaN，而整个流程没有任何报错。所以凡是涉及浮点除法、开方、日志等可能产生非法值的运算，我都会在关键节点用 isnan 和 isinf 显式检查。
4.4 所谓"精度"到底指什么
float 的有效精度约 7 位十进制，double 约 15~16 位十进制。这里说的"有效数字位数"是相对精度，不是小数点后固定几位。比如 123456789.0 用 float 保存，可能变成一个邻近值，因为 24 位有效二进制位只能覆盖约 7 位十进制。而 0.0000001 这种小数的相对误差也可能很大。
另一个常被误解的概念是 epsilon。FLT_EPSILON 等于 2^-23，是"1.0 与下一个可表示的 float 的间距"，不代表任何数值的绝对误差都是 1.19e-7。数值越大，相邻可表示浮点数的间隔越大——在大数附近，float 可能连 1 都区分不出来。
5. 精度损失实战：判等、累加、金额计算三个典型场景
5.1 0.1 + 0.2 不等于 0.3 的完整链条
最著名的现象是：
float a = 0.1f; float b = 0.2f; printf("%.20f\n", a + b); // 0.30000001192092895508double 版本：
>>> 0.1 + 0.2 0.30000000000000004原因在上面已经说过：0.1 和 0.2 在二进制里都是无限循环小数。double 只能保存最近似的两个值，把这两个近似值相加，结果又向 0.30000000000000004 这个最近的 double 落。整个链条没有一步是"算错了"，只是每一步都在做近似。
换句话说，浮点运算的结果应该理解为"落在某个区间内的不确定值"，而不是精确数。判断两个浮点数是否相等，就不再是直接的 == 比较问题。
5.2 判等、累加漂移的处理习惯
比较浮点数的标准做法是给一个误差容限。根据业务量级选择绝对容限或相对容限：
double x, y; double eps = 1e-9; if (fabs(x - y) < eps) { // 视为相等 }但绝对容限在数值很小时容易把明显不同的数判成相等，在数值很大时又过于严格。更稳妥的做法是按量级使用相对误差，比如fabs(x - y) <= eps * fmax(fabs(x), fabs(y))。
累加漂移是另一个高频问题。假设循环一亿次，每次都加 0.1，double 也会慢慢偏离理想值。对这种场景我一般两招：要么把循环变量改成整数，要么使用 Kahan 补偿求和。Kahan 的原理是维护一个小的补偿项，把每步丢失的低位误差"记下来"，下一轮再加回去：
double sum = 0.0; double c = 0.0; for (int i = 0; i < N; i++) { double y = x - c; double t = sum + y; c = (t - sum) - y; sum = t; }这段代码看着绕，但能显著降低长时间累加的误差漂移，很多数值库内部也用了类似的补偿思路。
5.3 金额计算：早该把浮点数踢出局
涉及金额的代码，我一律不用 float/double。思路是：把"元"换算成"分"用整数存储和运算，展示时再换算；或者使用专门的高精度 Decimal 类型。数据库层面用 DECIMAL/NUMERIC，不要用浮点列。原因很简单：钱不能近似，更不能让误差累加。虽然在单笔交易里浮点误差可能只有分毫，但累计到对账、结算、报表阶段，误差会被放大成对不上的账单。
用整数"分"的方案还有一个额外好处：跨语言传递时不存在精度协商问题。你不需要考虑对方是把数字解析成了 float 还是 double，因为整数在安全范围内是精确的。
5.4 跨语言和序列化场景的特殊提醒
跨语言传数值时，最大的坑是"类型收缩"。一个 double 在 A 语言里好好的，序列化成 JSON 后，B 语言按 float 解析，精度当场丢。另一个常见坑是 protobuf 之类的协议里，浮点字段只有 32 位，喂进去一个超出 float 精度的大数值，序列化再反序列化回来就已经变了。
我的处理原则是：如果数值可能超过 2^24（约 1677 万）或者需要精确到小数，通信协议里优先用字符串传递；如果必须用数值类型，明确区分 float32 和 double64，并在文档里写明精度承诺。
6. 排查数值异常时的三板斧：把内存里的字节请出来亮个相
6.1 C/C++ 里看裸字节
遇到数值问题，我最先做的永远是打印裸字节，而不是打印它格式化后的十进制。C 里用联合体或 memcpy 都行：
#include <stdio.h> #include <stdint.h> #include <string.h> int main(void) { float f = 149.99f; uint32_t bits; memcpy(&bits, &f, sizeof bits); printf("float 149.99 -> 0x%08x\n", bits); double d = 149.99; uint64_t bits64; memcpy(&bits64, &d, sizeof bits64); printf("double 149.99 -> 0x%016llx\n", (unsigned long long)bits64); return 0; }这会输出两个完全不同的十六进制，但都代表"149.99 的最近近似值"。把这两个 bits 看作同一个数在不同位宽下的存储快照，精度问题的根源就一目了然了。
6.2 解释器与标准库辅助验证
Python 的 struct 和 float.hex() 是验证 IEEE 754 问题的利器：
import struct # 看 float 的 32 位裸字节 print(struct.pack('>f', 149.99).hex()) # 大端四个字节 # 看 double 的精确十六进制表示 print((0.1).hex()) # 0x1.999999999999ap-4float.hex()的好处是它把尾数、指数直接以十六进制形式展开，一眼能看出"这个数的二进制形态"。C99 也支持printf("%a", 0.1)，输出0x1.999999999999ap-4。当你怀疑某个库是不是偷偷把 double 压成 float 时，用这个方式对比两端的 hex 是最快的。
6.3 控制变量法与边界对照
排查数值问题，我用的是控制变量法：把数据通路上的每一步都设置成可观测的中间节点，分别打印。比如同一份 149.99，分别走"文本 → float → double"和"文本 → double"两条路线，打印每一步的十六进制。两条结果在哪个节点分叉，问题就在哪。
另外有个小习惯：在调试浮点问题时，先确认当前机器的字节序；在看跨语言数据时，先确认双方的类型位宽；在判断数据合法性时，先用 isnan/isinf 把特殊值过滤掉。这些检查看似多余，但能省下大量查代码的时间。
最后分享一个我个人的原则：凡是进到"钱、量、时间"这类不允许误差的领域，在接口边界就把数值类型固化下来，要么整数，要么字符串，要么高精度十进制；凡是底层协议，明确字节序和位宽；凡是传感器或统计类数据，才放心用 float/double，并在展示层统一舍入。按这个原则做，至少能把八成"数据对不上"的故障，提前消灭在类型设计阶段。
