1. 为什么“数据的表示与运算”是所有计算机问题的起点很多人第一次看到“数据的表示与运算”这个标题会觉得它像是教科书里最枯燥的那一章——无非是二进制、原码反码补码、浮点数那一套。但我干了十多年底层开发和性能优化之后越来越确信一件事你在这上面偷的懒迟早会在某个深夜的调试现场加倍还回来。一个看似简单的整数溢出、一次浮点精度丢失、一个字节序理解错误都可能让整个系统在关键时刻崩掉。这一章要解决的核心问题其实就三个数据在机器里到底长什么样、这些表示方式会带来哪些坑、以及运算过程中有哪些反直觉的行为。它适合所有写代码的人——不管你是做前端、后端、嵌入式还是算法只要你的程序需要处理数字、字符串、布尔值你就绕不开这套底层规则。哪怕你平时用的是 Python 这种“帮你把细节藏起来”的语言一旦涉及性能调优、跨语言通信、序列化协议设计你还是得回到这一层来。我写这篇东西的目的不是把教材复述一遍而是把我这些年踩过的坑、做过的取舍、以及那些“当时要是有人告诉我该多好”的经验系统地摊开来讲。你会看到为什么补码能统一加减法、为什么浮点数的 0.10.2 不等于 0.3、为什么大端小端会让两个系统互相“看不懂”对方的数据。这些不是考试题是真实项目里会要你命的东西。2. 整数表示从原码到补码的进化逻辑2.1 原码、反码、补码到底在解决什么问题我们先从最基础的说起。假设你有一个 8 位的存储空间要表示有符号整数。最直觉的做法是最高位当符号位0 表示正1 表示负剩下 7 位表示数值大小。这就是原码。比如 5 是 0000 0101-5 是 1000 0101。看起来挺合理但它有两个致命问题。第一个问题是零有两个表示0000 0000 是 01000 0000 是 -0。这在逻辑判断时很烦你每次比较两个数是否为零都得处理两种情况。第二个问题更严重加减法不能统一处理。你用原码做 5 (-5)直接按位加会得到 1000 1010也就是 -10完全错了。这意味着 CPU 得为加法和减法设计两套电路成本高、速度慢。为了解决减法问题人们发明了反码负数的反码就是符号位不变、其余位取反。比如 -5 的反码是 1111 1010。这样 5 (-5) 变成 0000 0101 1111 1010 1111 1111再转回原码是 1000 0000也就是 -0。虽然结果对了但零还是有两个表示而且运算完还得再转一次麻烦。最终的赢家是补码。补码的规则是负数的补码等于反码加一。还是 -5反码是 1111 1010加一得 1111 1011。这时候 5 (-5) 0000 0101 1111 1011 1 0000 0000最高位溢出丢掉剩下 0000 0000正好是零。而且零只有一种表示。更妙的是补码把减法变成了加法a - b 等价于 a (-b 的补码)。CPU 只需要一个加法器就能搞定所有加减运算这是计算机体系结构里最漂亮的设计之一。注意补码能表示的负数范围比正数多一个。8 位补码的范围是 -128 到 127。为什么是 -128因为 1000 0000 在补码里被定义为 -128而不是 -0。这个“多出来的一个负数”在很多边界场景下会咬人后面会细说。2.2 整数溢出那个让你半夜惊醒的隐形杀手补码虽然优雅但它有个天生的限制位数固定能表示的范围就固定。一旦运算结果超出这个范围就会发生溢出。溢出的行为在 C/C 里是未定义行为UB在 Java 里是静默回绕在 Python 里则自动扩展成大整数。这三种不同的处理方式直接决定了你写出来的代码在不同语言里表现完全不一样。我举个真实的例子。假设你在做一个电商系统用 32 位有符号整数存商品价格单位是分。32 位有符号整数的最大值是 2,147,483,647也就是大约 2147 万分换算成元是 21,474,836.47 元。单笔订单超过两千多万在大多数场景下够用。但如果你做的是批发或者企业采购一笔订单上亿完全可能。这时候两个价格相加就会溢出结果变成负数你的系统可能直接把钱退给用户了。int price_a 2000000000; // 20,000,000.00 元 int price_b 2000000000; int total price_a price_b; // 溢出结果是负数 printf(%d\n, total); // 输出 -294967296这个坑的排查难度在于溢出不会报错不会崩溃只会静默地给你一个错误结果。你可能在测试环境用小额数据测得好好的一上生产就出问题。我的经验是凡是涉及金额、计数、索引的整数运算都要在脑子里过一遍“这个值最大可能到多少会不会超”。如果拿不准就用更大位数的类型或者用语言提供的安全运算库。实操心得在 C/C 里做金额计算我一般直接用 64 位整数哪怕当前业务用不到那么大。多出来的 4 个字节换来的安全感远比省那点内存值得。如果语言支持比如 Rust 的 checked_add优先用带溢出检查的运算方法出问题直接 panic 比静默错误好得多。2.3 无符号整数的陷阱减法回绕与循环边界无符号整数看起来简单——没有符号位所有位都用来表示数值范围是 0 到 2^n - 1。但它有个非常反直觉的行为减法结果如果为负会回绕成一个巨大的正数。比如 8 位无符号整数0 - 1 等于 255而不是 -1。这个特性在写循环的时候特别容易出事。你可能见过这样的代码for (unsigned int i n; i 0; i--) { // 处理 data[i] }这段代码看起来没问题但当 i 减到 0 之后再减一不会变成 -1而是变成 429496729532 位无符号最大值循环继续执行然后访问 data[4294967295]直接段错误。正确的写法是把循环条件改成i 0然后在循环体内单独处理 i0 的情况或者用有符号整数做循环变量。另一个常见场景是数组长度相减。假设你有两个无符号整数 a 和 b你想判断 a - b 是否大于某个阈值。如果 a ba - b 会回绕成一个超大正数你的判断逻辑就完全错了。这种 bug 在代码审查时极难发现因为表面上逻辑是对的。注意无符号整数不是“更安全的整数”它只是“没有符号位的整数”。在需要表示差值、偏移量、倒计时这类可能为负的场景下老老实实用有符号整数。只有在明确知道数值永远非负比如内存地址、哈希值、位掩码时才用无符号。3. 浮点数精度、舍入与那些反直觉的运算结果3.1 IEEE 754 的组成符号位、指数位、尾数位整数表示相对直观浮点数就复杂多了。现代计算机普遍采用IEEE 754 标准来表示浮点数。一个 32 位单精度浮点数被分成三段1 位符号位、8 位指数位、23 位尾数位。64 位双精度则是 1 位符号、11 位指数、52 位尾数。这个设计的核心思想是用科学计数法的二进制版本来表示一个数(-1)^符号 × 1.尾数 × 2^(指数-偏移)。偏移量对于单精度是 127双精度是 1023。为什么要偏移因为指数可能是负数表示很小的数但指数位本身是无符号的加个偏移就能把负数映射到正数范围。尾数部分有个隐含的“1.”也就是说实际精度是 24 位单精度或 53 位双精度。这个隐含位是 IEEE 754 的一个巧妙设计相当于白送一位精度。但这也意味着零无法用这个格式表示所以标准里专门规定了全零的指数和尾数表示零以及一些特殊值。类型符号位指数位尾数位总位数大致范围单精度182332±3.4×10^38双精度1115264±1.8×10^3083.2 为什么 0.1 0.2 不等于 0.3这是浮点数最著名的“bug”但它其实不是 bug而是二进制浮点数的固有特性。0.1 在十进制里是精确的但在二进制里是一个无限循环小数0.00011001100110011...。就像 1/3 在十进制里是 0.3333... 永远写不完一样0.1 在二进制里也永远写不完。计算机只能用有限的位数来存这个无限小数所以存进去的 0.1 实际上是 0.1000000000000000055511151231257827021181583404541015625双精度。0.2 同理。两个近似值相加结果自然不是精确的 0.3而是 0.3000000000000000444089209850062616169452667236328125。当你用比较时它们不相等。 0.1 0.2 0.30000000000000004 0.1 0.2 0.3 False这个问题的正确解法不是“用更高精度”而是改变比较方式。判断两个浮点数是否相等应该看它们的差值是否小于一个极小的阈值epsilon。或者如果业务场景要求精确小数比如金额直接用整数或十进制库别用浮点数。实操心得我见过太多人用浮点数存金额然后在结算时发现差几分钱。金额、税率、折扣这类需要精确十进制的场景要么用整数存最小单位分要么用语言提供的 Decimal 类型。浮点数只适合科学计算、图形渲染这类“精度够用就行”的场景。3.3 特殊值NaN、Infinity 与 -0.0IEEE 754 还定义了几个特殊值它们在运算中的行为非常反直觉。NaNNot a Number表示无效运算的结果比如 0/0 或负数开平方。NaN 最大的特点是它不等于任何值包括它自己。也就是说NaN NaN是 false。判断一个值是不是 NaN必须用专门的函数如 Python 的 math.isnan。Infinity表示溢出或除以零的结果。正无穷加正无穷还是正无穷但正无穷减正无穷是 NaN。这些规则在数学上自洽但在代码里很容易让人迷惑。比如你写一个排序算法如果数组里有 NaN排序结果可能完全乱掉因为所有比较都返回 false。-0.0是另一个奇葩。它在数值上等于 0.0但符号位不同。0.0 -0.0是 true但1/0.0是正无穷1/-0.0是负无穷。大多数时候你不需要关心它但在某些数值计算和图形处理场景下-0.0 会导致意外的结果。4. 字节序大端与小端的恩怨情仇4.1 什么是字节序为什么会有两种当一个多字节数据比如 32 位整数存到内存或通过网络传输时字节的排列顺序就成了问题。假设有一个 32 位整数 0x12345678它占 4 个字节12、34、56、78。在内存里你可以把高位字节 12 放在低地址也可以把低位字节 78 放在低地址。前者叫大端序Big-Endian后者叫小端序Little-Endian。这两种顺序没有谁对谁错纯粹是历史选择。大端序更符合人类阅读习惯高位在前小端序在硬件实现上有些便利低位在低地址类型转换时不用调整。x86 和 ARM 默认用小端序而网络协议TCP/IP规定用大端序。这就导致了一个经典问题你本机存的数据直接发给另一台机器对方可能读出来是错的。4.2 网络编程中的字节序转换做网络编程的人一定见过htonl、htons、ntohl、ntohs这几个函数。它们的作用就是在本机字节序和网络字节序之间转换。h 代表 hostn 代表 networkl 代表 long32 位s 代表 short16 位。发送数据前用 hton 转成大端接收数据后用 ntoh 转回本机序。uint32_t value 0x12345678; uint32_t network_value htonl(value); // 转成网络字节序 send(sock, network_value, sizeof(network_value), 0); uint32_t received; recv(sock, received, sizeof(received), 0); uint32_t host_value ntohl(received); // 转回本机字节序如果你忘了转换在小端机器上发出去的数据到了大端机器上就会变成完全不同的值。更麻烦的是如果两台机器都是小端你不转换也能正常工作测试时发现不了问题。一旦部署到混合架构的环境bug 才暴露出来。注意字节序问题不只出现在网络编程。读写二进制文件、跨平台共享内存、序列化协议设计只要涉及多字节数据都要考虑字节序。我个人的习惯是凡是跨进程、跨机器、跨平台的数据交换一律显式指定字节序不依赖任何默认行为。4.3 如何检测本机字节序有时候你需要知道当前机器是大端还是小端。最简单的方法是用一个联合体union或者指针转换int is_little_endian() { uint32_t x 1; return *(uint8_t*)x 1; }如果低地址存的是 1说明是小端。这个方法利用了“1 在内存里只有最低字节是 1”的特性。另一种方法是用联合体union { uint32_t i; uint8_t c[4]; } u; u.i 1; if (u.c[0] 1) { // 小端 } else { // 大端 }实际项目中我一般不会在运行时检测字节序而是在编译时通过宏判断如__BYTE_ORDER__这样编译器能直接优化掉分支。运行时检测只在极少数需要动态适配的场景下才用。5. 位运算那些让你代码快十倍的技巧5.1 基础位运算与常见用途位运算是直接操作二进制位的运算包括与、或|、异或^、取反~、左移、右移。它们的特点是极快——通常一个时钟周期就能完成比乘除法快得多。在很多性能敏感的场景下用位运算替代算术运算能带来数量级的提升。几个最常用的技巧判断奇偶x 1比x % 2快因为取模涉及除法。乘以 2 的幂x n等价于x * 2^n左移比乘法快。除以 2 的幂x n等价于x / 2^n对无符号数或有符号正数。交换两个数a ^ b; b ^ a; a ^ b;不需要临时变量。取绝对值对于补码整数(x ^ (x 31)) - (x 31)可以无分支地取绝对值。这些技巧在现代编译器面前可能已经被自动优化了但在嵌入式、游戏引擎、密码学等领域手写位运算仍然是常态。5.2 位掩码与状态压缩位掩码是用一个整数的不同位来表示多个布尔状态的技巧。比如一个 8 位整数可以表示 8 个开关状态每个位对应一个功能是否开启。这在权限系统、游戏状态、硬件寄存器操作中非常常见。#define FLAG_READ (1 0) // 0000 0001 #define FLAG_WRITE (1 1) // 0000 0010 #define FLAG_EXEC (1 2) // 0000 0100 uint8_t permissions 0; permissions | FLAG_READ; // 开启读权限 permissions | FLAG_WRITE; // 开启写权限 if (permissions FLAG_READ) { // 检查读权限 // 有读权限 } permissions ~FLAG_WRITE; // 关闭写权限这种写法的好处是节省空间8 个状态只占 1 个字节和操作高效一个位运算就能批量检查或修改。缺点是可读性差不熟悉的人看不懂那些魔法数字。我的经验是用宏或枚举给每个位起名字并且在注释里画出位布局图。5.3 移位运算的陷阱有符号右移与未定义行为移位运算看起来简单但有几个坑。首先左移超出位宽是未定义行为。比如一个 32 位整数左移 32 位结果在 C 标准里是未定义的不同编译器可能给出不同结果。其次有符号数的右移行为是实现定义的。算术右移会保留符号位负数右移还是负数逻辑右移则补零。大多数编译器对有符号数用算术右移但标准并没有强制。int a -8; int b a 1; // 可能是 -4算术右移或 2147483644逻辑右移为了避免这种不确定性我建议做移位运算时尽量用无符号整数。如果必须用有符号数先确认目标平台的行为或者用除法替代右移。另外移位数一定要做边界检查确保在 0 到 位宽-1 之间。实操心得我曾在一次性能优化中把x / 2改成x 1结果负数场景下结果不对。排查了半天才发现是算术右移和除法的舍入方向不同。除法是向零取整算术右移是向下取整。对于 -3 / 2除法得 -1右移得 -2。这个差异在正数场景下完全看不出来只有负数才会暴露。6. 字符与字符串的表示编码的前世今生6.1 ASCII、Unicode 与 UTF-8 的关系字符在计算机里也是用数字表示的。最早的是ASCII用 7 位表示 128 个字符包括英文字母、数字、标点和控制字符。后来扩展到 8 位变成 Latin-1能表示 256 个字符。但这对中文、日文、阿拉伯文等非拉丁语系完全不够用。Unicode是一个字符集给世界上每个字符分配一个唯一的编号码点。比如 A 是 U0041中 是 U4E2D。但 Unicode 只定义了编号没定义怎么存。UTF-8是一种编码方式把码点转成字节序列。它的特点是变长ASCII 字符占 1 字节中文通常占 3 字节emoji 可能占 4 字节。UTF-8 的设计非常巧妙它兼容 ASCII。所有 ASCII 字符在 UTF-8 里还是原来的单字节表示这意味着老的 ASCII 文本不需要转换就能被 UTF-8 解析器正确读取。这个特性是 UTF-8 能在互联网上统治的根本原因。编码字符范围字节数兼容性ASCIIU0000 - U007F1基础UTF-8U0000 - U10FFFF1-4兼容 ASCIIUTF-16U0000 - U10FFFF2 或 4不兼容 ASCIIUTF-32U0000 - U10FFFF4不兼容 ASCII6.2 字符串长度字符数、字节数与码点数“这个字符串有多长”这个问题答案取决于你问的是什么。对于 café 这个词字节数UTF-85 字节因为 é 占 2 字节。码点数4 个c、a、f、é 各一个。用户感知的字符数4 个。但对于 ‍‍‍ 这个家庭 emoji字节数25 字节。码点数7 个4 个人物 3 个零宽连接符。用户感知的字符数1 个。这种差异在处理用户输入、截断字符串、计算显示宽度时会造成大量 bug。比如你想截取前 10 个字符如果按字节截可能把一个多字节字符切成两半产生乱码。如果按码点截可能把 emoji 的组成部分拆散显示成几个独立的符号。注意做字符串截断时一定要用语言提供的“按字素簇”或“按用户感知字符”的 API。Python 的len()返回码点数不是字节数也不是字素数。JavaScript 的str.length返回 UTF-16 码元数对于 emoji 会返回 2 而不是 1。这些细节在面向用户的场景下必须搞清楚。6.3 编码转换中的乱码问题排查乱码的本质是用错误的编码方式解读字节序列。比如一段 UTF-8 编码的中文你用 Latin-1 去解码就会看到一堆 中 这样的字符。反过来一段 GBK 编码的文本用 UTF-8 解码可能直接报错或者显示成问号。排查乱码问题的思路是先确定原始字节是什么再确定应该用什么编码解码。我通常会用十六进制查看器看原始字节然后根据字节模式判断编码。UTF-8 的中文字节通常以 E4-E9 开头GBK 的中文是两个字节都在 0x81-0xFE 范围。如果字节序列不符合任何已知编码的规则那可能是数据在传输过程中被破坏了。# 查看原始字节 raw b\xe4\xb8\xad\xe6\x96\x87 print(raw.hex()) # e4b8ade69687 # 用正确编码解码 text raw.decode(utf-8) print(text) # 中文 # 用错误编码解码会得到乱码或报错 try: wrong raw.decode(latin-1) print(wrong) # ä¸æ except UnicodeDecodeError as e: print(f解码失败: {e})7. 常见问题与排查技巧实录7.1 整数溢出排查速查表现象可能原因排查方法解决方案金额变成负数32 位整数溢出检查最大值是否超过 21 亿改用 64 位或大整数循环无法退出无符号数减法回绕检查循环变量类型和条件改用有符号或调整条件数组越界索引计算溢出打印中间结果用更大类型或边界检查哈希值分布不均乘法溢出截断检查哈希函数实现用标准库哈希7.2 浮点数精度问题排查浮点数问题的排查核心是不要用 比较以及理解累积误差。如果你发现计算结果和预期有微小差异先检查是不是浮点精度问题。如果是金额相关直接换成整数或 Decimal。如果是科学计算评估误差是否在可接受范围内。一个实用的技巧是打印浮点数时用足够的精度。默认的print可能只显示 6 位小数掩盖了后面的误差。用%.17g或 Python 的repr()可以看到完整的双精度表示。7.3 字节序问题排查字节序问题的典型症状是数值完全不对但位数是对的。比如你期望收到 1000结果收到 38912。这时候把期望值和实际值都转成十六进制看看是不是字节顺序反了。如果是检查发送端和接收端是否都做了字节序转换。实操心得我处理字节序问题的习惯是在协议设计阶段就明确规定“所有多字节数值一律用大端序”然后在代码里封装统一的读写函数。这样业务代码不需要关心字节序所有转换都在底层完成。这个习惯帮我省了无数调试时间。7.4 字符编码问题排查编码问题的排查步骤第一确认原始字节第二确认应该用的编码第三检查转换链路中是否有环节用了默认编码。很多编程语言的默认编码在不同平台上不一样比如 Windows 中文版默认 GBKLinux 默认 UTF-8。跨平台项目一定要显式指定编码不要依赖默认值。8. 我在实际项目中的几点体会做了这么多年底层相关的工作关于数据的表示与运算我有几个反复验证过的原则。第一永远不要假设你知道数据在内存里长什么样。用sizeof确认类型大小用十六进制打印确认字节布局用标准库函数做转换。你的直觉在跨平台场景下经常是错的。第二边界条件比正常情况重要十倍。整数溢出、浮点特殊值、空字符串、零长度数组这些边界才是 bug 的高发区。写代码时多问自己一句“如果这个值是 0 会怎样”“如果是负数会怎样”“如果是最大值会怎样”。第三性能优化之前先保证正确性。位运算确实快但如果你为了用位运算而引入了一个隐蔽的 bug那点性能提升完全不值得。先用清晰的方式写对再用 profiler 找到真正的瓶颈最后才考虑用位运算或其他技巧优化。最后分享一个小技巧当你怀疑是数据表示问题时把值转成二进制打印出来。很多问题看一眼二进制就明白了——符号位在哪、指数位是多少、字节顺序对不对一目了然。这个方法比任何调试器都直接。