做了十多年开发，面试过不少人，也被人面试过不少次。我发现一个很有意思的现象：很多能写复杂业务逻辑的人，一问到"进制转换与各种变量"这种基础题，反而容易卡壳。给你一个十进制数 127，让你当场换算成二进制、八进制、十六进制，不少人都要掏出手机才敢回答。这篇文章我想把这两块内容彻底讲透——进制转换到底在转什么，各种变量在计算机里到底是怎么存的。适合刚入门的同学打地基，也适合写了几年代码但一碰位运算、内存调试就心里发虚的老开发做一次系统性复习。内容里会给出具体的计算方法、实战案例和踩坑记录，不搞虚的。

1. 进制不是数学题，是计算机的底层语言：为什么机器只认二进制

1.1 电路只有开和关，二进制是物理层面的必然

很多人把进制当成纯数学概念，觉得"二进制不就是用 0 和 1 表示数嘛"。这个理解本身没错，但它忽略了一个最关键的问题：为什么偏偏是二进制，而不是十进制或者十二进制？

答案藏在计算机硬件里。无论是 CPU 还是内存，归根结底都是大量晶体管和逻辑门电路构成的。一个晶体管在电路里基本只有两种稳定状态：导通或者截止，对应高电平和低电平。你可以把这两种状态想象成房间里的开关——灯要么亮，要么灭，不存在"半亮半灭"还能稳定工作的状态。为了让电路设计简单可靠，计算机采用了二值逻辑，也就是用 0 和 1 两个符号来表示这两种物理状态。

这里面有一个非常重要的点：计算机里其实不存在"十进制数"这个东西。我们看到的 255 这个十进制数，在内存里是 11111111 这 8 个位（bit）的电平状态。所谓进制转换，本质上是同一个数值在不同"记数规则"下的符号化表达发生变化，数字本身没有变，变的只是书写形式。想明白这一点，后面学变量、学位运算、学内存布局都会顺很多。很多初学者喜欢死记"二进制怎么转十六进制"的公式，其实只要抓住"数值不变、规则变了"这个核心，所有转换方法都能推导出来。

1.2 八进制和十六进制：不是给机器用的，是给人用的缩写协议

既然机器只认二进制，那为什么还要有八进制、十六进制？这里先澄清一个常见的误解：八进制和十六进制并不是计算机内部使用的进制，而是为了方便人类阅读和书写二进制，在"二进制之上"建立的一种缩写。

道理很简单：二进制写起来太长了。一个 32 位的整数，写成二进制是 32 个 0 和 1，写成十六进制只有 8 位。比如十进制 4294967295，二进制是 11111111111111111111111111111111，十六进制是 FFFFFFFF，书写量差距一目了然。

那为什么偏偏用 8 和 16，而不是 10 或者 12？因为 8=2^3，16=2^4，它们和二进制之间存在非常整齐的整除关系：3 个二进制位恰好对应 1 个八进制位，4 个二进制位恰好对应 1 个十六进制位。这意味着你可以在"不进行任何数学运算"的情况下，直接分组完成转换。回忆一下十六进制的字符表：0-9 对应数值 0-9，A-F 对应数值 10-15。每一组 4 位二进制数，从 0000 到 1111，正好对应十六进制的一位字符。八进制更简单，3 位一组，000 到 111 对应 0 到 7。

在实际项目中，十六进制的出场率远高于八进制。你会看到内存地址、调试器的反汇编代码、颜色值、文件头标识（magic number）全都用十六进制展示。八进制同样有用武之地，最典型的是服务器操作系统下的文件权限位，755、644 这些你天天见，它们本质上是 3 个八进制数字，分别代表文件所有者、所属组、其他用户三方的权限组合。把权限值拆成二进制再看就非常清楚：7 是 111，表示读、写、执行三项权限全开；5 是 101，表示读和执行，但没有写权限。

1.3 十进制的惯性：人脑转换慢的根源在"记数习惯"

既然写代码的人和机器都不需要十进制交流，那为什么我们学进制时总是习惯拿十进制当"中转站"？

因为人脑从小学的是十进制，天然习惯用十进制去理解数量大小。比如看到 0xFF，第一反应是"这个数大概多大"，得先把它换成十进制 255 才有具体概念。这种习惯本身没问题，但会导致一个效率困局：你在做进制转换时，往往不自觉地"先转十进制，再从十进制转目标进制"，白白多绕一个弯。

举个例子，把二进制 10110110 转成十六进制。如果你先转十进制：128+32+16+4+2=182，再从 182 转十六进制：182÷16=11 余 6，得到 0xB6。两边都对，但明显绕了远路。更快的做法是直接 4 位一组：1011 对应十六进制的 B，0110 对应 6，结果就是 0xB6。熟练使用直接分组法之后，你的转换速度会提升一个量级，后面我会详细讲这个方法。说到底，转换慢不是因为数学差，而是没有摆脱十进制的思维惯性。

2. 手算不吃力：我整理的四套实用转换方法

2.1 整数转换首选"除基取余法"

整数部分从十进制转任意进制，最通用、最不容易出错的算法就是"除基取余"：用目标进制的基数不断去除十进制数，把每次的余数从下往上排列。

拿十进制 89 转二进制举例：

89 ÷ 2 = 44 余 1
44 ÷ 2 = 22 余 0
22 ÷ 2 = 11 余 0
11 ÷ 2 = 5 余 1
5 ÷ 2 = 2 余 1
2 ÷ 2 = 1 余 0
1 ÷ 2 = 0 余 1

把余数从下往上读：1011001，这就是 89 的二进制形式。验证一下：64+16+8+1=89，正确。

这个方法最大的优点是可以机械执行，只要老老实实除到底就不会错。同理，转八进制就不断除以 8，转十六进制就不断除以 16，余数大于 9 时用 A-F 表示。比如 89 转十六进制：89÷16=5 余 9，结果是 0x59。

如果你已经有了二进制结果，想快速转八进制或十六进制，不用重新除，直接分组即可：把 1011001 从右往左 3 位一组得到 001 011 001，对应八进制 131；4 位一组得到 0101 1001，对应十六进制 0x59。这里要特别注意：分组必须从右往左，最左边一组不足位数时补前导 0，补出来的 0 不改变数值大小，只是为了凑齐分组宽度。

2.2 小数转换用"乘基取整法"

带小数的十进制数转二进制，整数部分和小数部分必须分开处理。整数部分用除基取余法，小数部分用"乘基取整法"：不断用小数部分乘以目标基数，每次取乘积的整数部分，从上往下排列。

以十进制 0.625 转二进制为例：

0.625 × 2 = 1.25，取整数 1，剩下 0.25
0.25 × 2 = 0.5，取整数 0，剩下 0.5
0.5 × 2 = 1.0，取整数 1，剩下 0.0

从上往下读整数部分：101，所以 0.625 的二进制是 0.101。验证：1×2^(-1) + 0×2^(-2) + 1×2^(-3) = 0.5 + 0 + 0.125 = 0.625，正确。

这里有一个很多人没意识到的坑：二进制小数不一定能写尽。比如十进制 0.1，你用乘基取整法一直算下去会发现，小数部分永远循环进位不完，0.1 在二进制里是一个无限循环小数，就像 1/3 在十进制里无限循环一样。我在后面讲浮点数时会专门展开，这是无数精度 bug 的根源。遇到实在转换不完的情况，只能根据需要的精度截断，而截断就必然带来误差，这是二进制浮点表示逃不掉的宿命。

2.3 8421 分组法：二进制与十六进制互转的"肌肉记忆"

如果说整数转换最稳的算法是除基取余，那二进制和十六进制之间互转，最快的算法一定是 8421 分组法。

8421 这个名字来自 4 位二进制数的位权：从高位到低位分别是 8、4、2、1。每一组 4 位二进制数，相当于把这几个权值中命中的项加起来。比如 1010，最高位 1 表示有 8，第二位 0 表示没有 4，第三位 1 表示有 2，最低位 0 表示没有 1，结果就是 8+2=10，对应十六进制字符 A。

十六进制转二进制就是反向操作：把每一位十六进制字符拆成 4 位二进制。比如 0x7F，7 拆成 0111（4+2+1），F 拆成 1111（8+4+2+1），合起来就是 01111111，去掉前导 0 得到 1111111。反过来，二进制 1111111 从右往左分组刚好是 0111 1111，对应 0x7F。

我建议你把 0 到 F 对应的 4 位二进制列成一个表，反复练到看到 A 就反射出 1010、看到 C 就反射出 1100 的程度：

这个反射速度在排查网络报文、解析二进制文件、阅读调试器输出时会省下大量时间。十六进制和八进制互转，我一般建议先转二进制做跳板，原理上仍然只是分组，只是分组宽度不同，先十六进制拆成 4 位一组，再重新按 3 位一组拼成八进制。

2.4 负数与补码：进制转换中最容易翻车的一步

很多入门教材讲进制转换只讲正整数，导致一遇到负数就懵。实际上计算机里负数并不是"负号加一个二进制数"这么简单。绝大多数处理器采用补码（two's complement）表示有符号整数。这里直接给结论：在 n 位二进制中，一个负数 -x 的补码等于 2^n - x。

举例：8 位二进制下，-5 的补码是多少？2^8 - 5 = 251，把 251 转二进制得到 11111011。另一种更常用也更直观的算法是分三步：先写 5 的二进制 00000101，按位取反得到 11111010，再加 1 得到 11111011。两种算法结果一致。

为什么要用这么绕的方式？因为补码让加法和减法统一成了加法——CPU 只需要一个加法器，不需要单独的减法器。-5 直接以 11111011 参与加法，任何数和它相加都等价于减 5。同时补码还保证了 -1 是所有位全为 1（8 位下是 11111111），0 只有一种表示方法，不像原码或反码会出现 +0 和 -0 两种零。这些设计细节在实际开发中非常重要，尤其是你处理有符号整数的位运算、判断溢出、做协议解析时。

所以做题时看到"负数的二进制是什么"，第一件事是确认位宽。同样一个 -5，8 位下是 11111011，16 位下是 1111111111111011，前面补了一堆 1。这种"符号扩展"（sign extension）在类型提升、跨字节拼接时经常出现，不搞清楚就很容易掉进坑里。

3. 变量类型的本质：位、字节和解释方式

3.1 变量不是"贴了标签的盒子"，而是内存地址的别名

大部分编程教材会把变量比喻成"装数据的盒子"，这个比喻在入门阶段挺友好，但到了进阶阶段反而会误导人。真实情况是：变量名本质上是编译器替你管理的一个内存地址的别名。你在代码里写 int a = 5; 编译器会在内存中划出 4 个字节（实际大小取决于平台），把这 4 个字节解释为一个有符号整数，并把起始地址关联到名字 a 上。

理解这个区别有什么用？用处非常大。第一，你就能理解为什么变量有"生命周期"和"作用域"——它背后是内存分配和释放的时机。第二，你就能理解为什么类型这么重要——同一块内存，你把它解释成 int、float、char 数组或者指针，得到的意义完全不同。第三，你就能理解传值和传引用的本质差异：传值复制的是字节内容，传引用传的是地址本身。

我记得在某项目里排查一个诡异 bug，最后发现是因为把一个 4 字节结构体的地址强行当成字符串指针打印，导致输出了完全不可读的乱码。问题不在数据本身，而在解释方式用错了。这个例子让我彻底意识到：对变量的理解停留在"盒子"层面是不够的，必须上升到"地址 + 字节 + 解释规则"三层模型。

3.2 整数类型的边界：溢出不是出了 bug，是算术的必然结果

各种变量里最基础的分类是整数类型。不同语言有不同的类型体系，但底层逻辑惊人一致：类型名里往往直接写明位宽，比如 int8、int16、int32、int64，或者带 unsigned 前缀表明是否允许负数。

n 位无符号整数的取值范围是 0 到 2^n - 1；n 位有符号整数（补码表示）的取值范围是 -2^(n-1) 到 2^(n-1) - 1。拿 8 位举例：无符号能表示 0 到 255，有符号能表示 -128 到 127。一张表可以看得很清楚：

整数一旦超出边界，就会发生"回绕"（wrap around）：无符号整数溢出后从 0 继续往上数，有符号整数溢出后从最小值继续往上数。最经典的例子是把无符号 8 位整数 255 加 1，结果变成 0；把有符号 8 位整数 127 加 1，结果变成 -128。在很多语言里这不会报错，它就是这么"安静"地错了，等你在业务逻辑上发现时，往往已经被误导很久。

我自己的经验是：凡是涉及文件大小、时间戳、计数器增长、分页偏移量计算的场景，都要提前判断会不会越界，必要时换更宽的整数类型，或者做显式的溢出检查。千万别抱着"数字没那么大"的侥幸心理，线上数据一旦膨胀起来，溢出往往来得猝不及防。

3.3 浮点数陷阱：0.1 在二进制里根本"写不完"

浮点数是各种变量里坑最多的一类。几乎所有现代语言都遵循 IEEE 754 标准，用科学计数法的二进制版本来表示实数：一个数被拆成符号位、指数位、尾数位三部分。float 是 32 位（1 位符号、8 位指数、23 位尾数），double 是 64 位（1 位符号、11 位指数、52 位尾数）。

前面我说过，十进制 0.1 转二进制是无限循环小数，而浮点数的尾数位是有限的，所以计算机存 0.1 时只能截断近似。这就是为什么 0.1 + 0.2 在很多语言里算出来不是 0.3，而是 0.30000000000000004。这本身不是"编程语言写错了"，而是二进制浮点表示的固有精度限制，和十进制里 1/3 永远写不尽的道理一样。

面对这个特性，我的实操建议有三条。第一，金额计算不要用浮点数，用整数的最小单位（比如分），或者用专用的十进制定点类型。第二，比较浮点是否相等不要用 ==，要判断两者之差的绝对值是否小于一个合理的误差阈值。第三，如果必须做高精度的小数运算，用专门的高精度库，让底层自己做有理数或十进制表示，不要自己拿 double 去拼精度。这三点我在无数项目里验证过，照着做能避开绝大多数浮点翻车现场。

3.4 字符、布尔、字符串：类型是"解释规则的集合"

字符类型看起来和数字无关，但本质上字符就是数字：计算机存储的仍然是二进制数，只是被解释成某个字符编码表里的符号。最常见的编码是 ASCII，用 7 位二进制（实际存储常占 1 字节）表示 128 个字符，大写字母 A 是十进制的 65，小写字母 a 是 97，数字字符 '0' 是 48。这也解释了为什么在 C/C++ 里 'A' + 1 会得到 'B'，因为这个运算本质上就是 65 + 1 = 66，再把 66 解释成字符。

中文字符就比较复杂了。Unicode 给每个字符分配唯一的码点（code point），但码点的存储方式又有 UTF-8、UTF-16、UTF-32 等多个编码方案。UTF-8 是变长编码，英文字符占 1 字节，中文通常占 3 字节。这里提醒一个最常见的坑：用某些语言的字符串长度函数统计"中文字符串长度"时，拿到的往往是字节数而不是字符数，因为一个中文字符要占多个字节。当年我在某日志系统里统计消息长度，直接拿字节数当字符数去做截断，结果把好好的中文消息从中间截成乱码，排查了半天才发现是长度单位搞错了。

布尔类型更直白。很多语言的 bool 在底层就是一个整数：0 表示 false，非 0 表示 true。因为这个设计，你才会看到 C 语言里 if (x) 这种写法合法，也才会遇到某些动态语言里 0 == false 返回 true 这类让新手困惑的隐式转换。理解"布尔值本质上是 0 和非 0"这条规则，比死记各种语言的比较表有用得多。

4. 实战中的进制与变量翻车现场

4.1 颜色、文件头、网络协议：进制其实每天都在你眼皮底下

很多人觉得进制转换是考试题，实际工作中用不到，但只要你做开发，几乎天天在和十六进制打交道。

前端切图调样式，十六进制颜色是标配，比如 #FF8800 就是红绿蓝三通道各占一个字节 FF、88、00。你要是看懂了 8421 分组法，一眼就能判断这个颜色里红色分量拉满、绿色约占 53%、蓝色完全没有。同理，rgba() 函数里的透明度 0.5 在底层是浮点数，但如果要转成 8 位无符号整数的 alpha 通道，就得做 0.5 × 255 ≈ 127 或 128 的取整操作。

文件解析更是重灾区。很多文件格式的开头几个字节是"魔数"（magic number），用来标识文件类型。比如你写一个解析器，读取文件前 4 字节发现是 0x89504E47，就能判断这是 PNG 文件。这里面还涉及一个重要的点：多字节数字的存储顺序。一个 4 字节整数 0x12345678，在内存里可能是按 12 34 56 78 的顺序存（大端），也可能是 78 56 34 12（小端），不同平台、不同协议各有约定。网络协议一般统一使用大端序（也叫网络字节序），而最常见的桌面 CPU 平台一般是小端序。跨端解析时如果少做了一次字节序转换，读出来的整数就会完全对不上。我遇到过不止一次：报文里解析出的端口号明明是 12345，结果代码里读出来是 14640，就是因为字节序没翻转。

4.2 隐式转换与精度丢失：排查那些"看上去没问题"的 bug

变量类型在实战中最大的隐患是隐式类型转换。这里挑一个最常见的例子：整数除法。在 C 和很多类似语法里，两个 int 相除结果还是 int，小数部分被直接截断。某同学写 3 / 2 想拿 1.5，结果拿到 1，硬是查了半小时才发现需要至少把一个操作数写成浮点数，比如 3.0 / 2 或者 3 / 2.0。这个规则在不同语言里行为还不一样，做跨语言移植时必须重新确认。

还有一种更隐蔽的精度丢失：大整数转浮点数。一个 64 位整数，最大值是 2^63 - 1，而 double 的尾数只有 52 位，这意味着从某个数量级开始，double 根本无法精确表示每一个整数。把大整数塞进 double 再转回来，很可能得到一个"看起来差不多"但实际已经变了的值。我在某统计系统里遇到过：一个 18 位的订单号在存放时被当成了浮点数处理，前端展示时末尾两位变成了 0，导致订单号对不上。排查了很久才发现是序列化框架默认把大整数按浮点数处理的机制在作怪。所以，涉及 ID、金额、时间戳这种需要精确相等的数据，一律走整数类型或字符串，不要碰浮点。

4.3 跨语言跨平台：同样的字节，不同的解释

不同的编程语言对同一种变量类型往往有不同的大小和默认行为。最常见的差异是 int 的位宽：C 标准只保证 int 至少 16 位，实际上你在 64 位桌面平台上几乎总能得到 32 位，但在某些嵌入式平台、老代码库里 int 可能真的只有 16 位。如果你在一套系统里用 int 存了超大数值，又在另一套系统里用 int 去解析，结果很可能是对不上的。

我的建议是：在需要明确位宽的场合，永远优先使用带固定位宽的类型，比如 int32_t、uint64_t 这类名称，不要依赖 int 或 long 的具体大小。同时，跨语言交互（比如写文件、发消息、调二进制接口）时，还要考虑结构体的对齐和填充字节。两个语言的结构体字段顺序一样、类型声明一样，但因为默认对齐规则不同，实际在内存里占用的字节数可能不一样，解析偏移一旦按错，后面的字段全乱。这种问题我建议用明确的序列化格式（比如带长度和类型标记的协议）来规避，而不是赌两边的编译器行为一模一样。

5. 工具、习惯与自查清单

5.1 我常用的进制转换工具和命令行技巧

虽然我前面教了手算方法，但实际干活时没必要每次都手算，工具该用就用。优先级从高到低，我首推的是终端自带的工具，以及几乎所有主流语言的一句话命令。

在终端里，最常用的是 printf 配合格式说明符。printf 不能直接输出二进制，但能输出八进制和十六进制：

printf "%d\n" 0xFF # 十六进制转十进制，输出 255 printf "%o\n" 255 # 十进制转八进制，输出 377 printf "%x\n" 255 # 十进制转十六进制，输出 ff printf "%X\n" 255 # 十进制转十六进制，输出大写的 FF

Python 做进制互转更自由，因为自带 bin、oct、hex 和 int 函数：

bin(255) # '0b11111111' hex(255) # '0xff' oct(255) # '0o377' int('11111111', 2) # 255 int('ff', 16) # 255

桌面系统自带的计算器也有程序员模式，可以在进制之间直接切换，还能看到每一位的位权，调试位掩码时非常方便。另外提醒一句：很多十六进制编辑器都能以十六进制和 ASCII 双栏显示文件内容，解析二进制文件时是刚需，别等到要打开文件才发现自己连查看工具都没有。

5.2 排查变量问题时我执行的三个动作

当代码里出现"值是错的，但看不出哪里错"的情况，我通常按固定顺序做三步排查。

第一步，把所有相关变量的"类型"和"位宽"确认一遍。很多语言里直接用 size 类函数就能拿到机器上的实际字节数，先确认你头脑里假设的位宽和运行时真实位宽一致。第二步，用十六进制形式打印数值，而不是十进制。一个数长什么样，用十进制看不出端倪，但十六进制可以一眼看出字节构成。比如你按有符号类型打印一个值，预期是 0xFFFFFFFF，结果被解释成 -1，那是解释方式用错了；预期一个正数加一之后还是正数，结果变成 0x80000000，那多半是溢出；预期收到 0x1234，结果打出来是 0x3412，那就要怀疑字节序。第三步，在边界值处打点，比如加一、减一、翻倍、取反，快速定位是哪种类型的边界被击穿了。

这套方法我用了很多年。它不见得每次都能直接定位问题，但至少能把问题快速收敛到"进制表示错误"还是"类型解释错误"这两个大类里，排查效率比瞎猜高出不少。

5.3 一个值得长期养成的习惯：用十六进制思考整数

最后说一个个人体会最深的建议：不要只在需要转换时看十六进制，要习惯在写代码时就用十六进制来思考整数。

比如你要设置一个 8 位掩码，想保留低 3 位，最直观的写法是 mask = 0x07，比写成 mask = 7 清楚得多；想表达"最高位是 1、其他位是 0"，0x80 比 128 更能让人一眼看出它对应的二进制是 10000000。再比如位运算的标志位，枚举值写成 0x01、0x02、0x04、0x08，比 1、2、4、8 直观得多，还能防止别人把 3 误当成一个独立标志。这个习惯养成之后，你会发现位运算代码的可读性和可维护性会上一个台阶，别人评审你的代码时也不需要来回换算。