整型、浮点型、内存、存储——这几个词放在一起，基本就是C语言初学者从"会写代码"到"懂写代码"的一道分水岭。很多教程讲数据类型就是一张表：int占4个字节、float占4个字节、double占8个字节，然后就没然后了。可是等你真去处理网络协议、解析二进制文件、做嵌入式开发，或者只是想把一个float用联合体拆成字节来看，你会发现教科书上那张表完全不够用。我自己带过不少新手，也见过太多人卡在"为什么负数存储成补码""为什么0.1加0.2不等于0.3"这类问题上，说到底就是没有建立"数据在内存里到底长什么样"的画面感。
这篇文章就从C语言初识者的视角出发，把整型和浮点型在内存中的存储机制完整拆一遍。不需要你有多深的硬件底子，只要跟着一步一步走，把每一个十六进制、每一段内存布局都看明白，你之后学指针、学结构体、学文件读写，都会顺畅很多。
1. 为什么非要搞懂"数据在内存里长什么样"
整型和浮点型都属于C语言里的基本数据类型，平时声明变量就是写一个int a = 5;或者float f = 3.14;就完事了。但"声明变量"只是告诉编译器你需要一块内存，至于这块内存里到底以什么形式存放数据、为什么同一个二进制序列解释出来的数值会不同，绝大多数教程都默认你"自己会悟"。
我先说一个我见过无数次的经典场景。初学者写了一个无符号整型变量，赋值为-1，然后printf("%u", a)打印出来，发现结果是4294967295。这个时候第一反应是"我代码写错了"，第二反应是"编译器出bug了"。其实都错怪了代码和编译器，单纯是因为你还没搞明白：内存里存的是-1的补码，也就是0xFFFFFFFF，用无符号格式去解读，它自然就变成了4294967295。这就是存储格式与解读格式不匹配造成的"误会"。
往深一层说，计算机不会区分一个二进制序列是整数还是小数，是正数还是负数，是字符还是地址。CPU只是按照指令把这些二进制数据搬来搬去、做运算，至于"这一步要按什么格式来解释"，是编译器根据变量的类型在编译期就定好的。理解了这一点，你会发现很多C语言里"莫名其妙"的现象，其实都有着非常精确的底层解释。
这篇博文要做的，就是把整型和浮点型的存储规则拆开揉碎，从原码反码补码、大小端字节序、IEEE 754浮点格式这几个大方向入手，配合可运行的验证代码，帮你在脑袋里真正建立起"内存存储模型"。
注意：看懂这篇文章不需要任何额外工具，C语言配合一个调试器（Visual Studio或者gdb都可以）就够了。
2. 整型在内存中的存储：原码、反码与补码
2.1 补码这种"绕弯子"的设计，究竟在解决什么问题
先看整型。整型在内存中存储的核心概念就是三个：原码、反码、补码。很多教材一上来就背规则：正数的原反补相同，负数反码是原码符号位不变其余取反，补码是反码加1。但光背这三句话没有用，你必需知道这个设计是为了什么。
我们以8位二进制来举例。如果直接使用原码存储，也就是最高位当符号位，剩余7位存数值的绝对值，那么+1是00000001，-1是10000001。表面看起来很直观，但一涉及运算就麻烦了。CPU做加法时，如果不做特殊处理，1 + (-1)应该等于0，但原码直接相加是00000001 + 10000001 = 10000010，也就是-2，结果错了。所以用原码做算术运算，必须让CPU额外判断符号，电路设计要求复杂得多。
补码的出现解决了两个核心痛点。第一个痛点是让减法和加法共用同一套电路：1 - 1可以直接变成1 + (-1)。第二个痛点是避免"正0"和"负0"同时存在，把一位二进制数值空间充分利用起来。8位二进制原码能表示的范围是-127到127，但补码能表示-128到127，多出来一个-128，数值范围更大。
具体规则再快速过一遍：对于一个正整数，它的原码、反码、补码完全一样。对于一个负整数，原码是符号位为1、绝对值按普通二进制写；反码是符号位不变、其余各位取反；补码是反码加1。比如8位下的-5：原码是10000101，反码是11111010，补码是11111011。
为什么"反码加1"这个操作能直接参与加法运算？我给你一个直观的理解方式。把补码看成"模运算"体系：8位二进制数天然按256取模，于是-x就是256 - x的二进制表示。-1对应256 - 1 = 255，也就是11111111。-5对应256 - 5 = 251，也就是11111011，和上面通过原码求反码再加1的结果完全一致。把负数映射到"模空间"里的大数，减法就变成了加法，二进制加法器一条路走到底，硬件设计简单、速度快。这才是补码真正牛的地方。
2.2 有符号与无符号：同一段内存，两种解读
C语言里一个整数变量被声明为signed int还是unsigned int，直接影响编译器怎么去解读那4个字节（32位平台下）。
unsigned int简单明了，4个字节32位全是数值位，取值范围0到4294967295。signed int则让最高位承担符号功能，取值范围-2147483648到2147483647。你注意看，负数的最小值不是-2147483647而是-2147483648，原因就在前面刚说过：补码体系里8位能多表示一个-128，扩展到32位就是多表示一个-2147483648。
这里我想强调一个特别容易踩的坑：有符号整型的溢出属于"未定义行为"，但无符号整型的回绕是"完全定义行为"。C语言标准明确指出，无符号整型的运算遵循模运算规则，也就是说加到最大值再往上加一遍，会直接回绕到0；而带符号整型溢出则无任何保证，不同编译器不同优化级别可能出现不同结果。写代码时，如果预期可能溢出，请务必使用无符号类型，或者在大数场景改用更大位数的类型。
有符号和无符号的转换规则也值得单独说。C语言中存在隐式转换：当有符号和无符号出现在同一个表达式中时，有符号的值会被隐式转换为无符号。这就是为什么我在开头提到的printf("%u", -1)能打印出4294967295，因为在传给printf之前，-1已经被当作无符号整型来解读了。类似的，-1 > 1U这个比较表达式的值是"真"，这个结果困扰过无数C语言新手。
2.3 亲自看一眼：如何用调试器验证整型存储
光讲理论不练等于没讲。这里我用一段最简单的代码，让你在调试器里亲眼看到补码的样子。
#include <stdio.h> int main(void) { int a = 5; int b = -5; unsigned int c = 300; printf("a = %d, b = %d, c = %u\n", a, b, c); return 0; }在Visual Studio中编译调试版程序，在printf那一行打断点，运行时打开"调试-窗口-内存"，地址栏输入&b，选择"4字节整数"格式查看。你会看到b = -5的内存区域显示为FB FF FF FF（小端序），转换成十六进制整数值就是0xFFFFFFFB，和前面推算的-5补码完全一致。再去看a = 5，内存显示05 00 00 00，也就是0x00000005，完全是原码也就是它本身。
如果你没有调试器，也可以通过C语言的联合体或者指针来"自己看"内存的十六进制，后面我会给一套纯代码方案的代码，先不重复。
3. 大小端字节序：同一段数据，排列顺序不同
3.1 为什么会有大端和小端之分
整型存储还有一个绕不开的话题：字节序。所谓字节序，就是多字节数据在内存地址上的排列顺序。假设一个int变量的值是0x12345678，低地址那一个字节存的是0x12还是0x78？如果存的是0x12，也就是"高位字节在前"，叫大端序；如果存的是0x78，也就是"低位字节在前"，叫小端序。
名字的由来挺有意思。"大端"指内存地址从大头开始放，"小端"指内存地址从尾巴开始放。目前主流的x86、x86-64、ARM小端模式用得更多，而网络协议里大量使用大端序，这直接导致跨平台传输二进制数据时必须做字节序转换。
其实不同厂商选择哪种字节序，本质是工程上的权衡。小端序的额外好处是：当你在做多精度整数运算或者类型强转时，低字节放在低地址，CPU截断数据时可以直接从低地址读取，不需要偏移。大端序则更符合人类阅读十六进制时的直觉，"内存打印出来就是从左到右读成整数"。没有哪一边绝对更优，只能说历史选择。作为应用层开发者，你需要做的是"感知字节序"，而不是"评判字节序"。
3.2 一个函数检测当前机器是哪种字节序
写程序检测当前系统字节序，一行晦涩的代码就够了：
#include <stdio.h> int main(void) { unsigned int x = 0x12345678; unsigned char *p = (unsigned char *)&x; if (p[0] == 0x78) { printf("Little-endian\n"); } else if (p[0] == 0x12) { printf("Big-endian\n"); } else { printf("Unknown\n"); } return 0; }核心原理就是：指向int的指针被强制转换为unsigned char *，这样每次访问一个字节，我们就能看到这个四字节整数在内存里的真实排列顺序。在我的x86笔记本上，运行结果是Little-endian，因为在内存中低地址0号字节存放的就是最低位字节0x78。
除了这种运行时检测，还可以在编译期用预处理器宏判断（__BYTE_ORDER__、__ORDER_LITTLE_ENDIAN__等），各编译器的支持情况略有差异。多数情况下建议运行时检测，因为只要代码正确，它既在x86上有效，也能在ARM、RISC-V等平台上自动适配，更通用。
3.3 字节序在实际开发中的坑
字节序的坑通常在两个场合集中爆发。第一个是网络编程，TCP/IP协议栈为了跨平台统一，规定多字节整数一律使用大端序传输，也就是大家口头上常说的"网络字节序就是大端序"。如果你在x86小端机器上直接send一个结构体，对方用大端机器去解析，读出来的整数就会变成完全不同的数值。正确的做法是发送前用htonl、htons转换成网络序，接收后再用ntohl、ntohs转回主机序，这两组函数在Windows、Linux、macOS上都有，跨平台性非常好。
第二个坑是解析二进制文件格式。比如PNG图片头部有宽度和高度字段，都是四字节大端整数；再比如某些嵌入式采集设备输出的原始二进制数据，可能直接用小端存储。你拿C语言去解析时，绝不能直接*(int *)p去读，必须先按字节取出来，再根据文件规定的字节序手动拼接成整数。正确的做法是用移位和或操作：
uint32_t read_big_endian_32(const unsigned char *p) { return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) | ((uint32_t)p[2] << 8) | ((uint32_t)p[3]); }为什么非要用移位而不是强制转换？因为强制转换会按当前机器字节序去解释那段内存，得到的值和文件里实际存的整数对不上。这个坑我见到太多人踩过了。
4. 浮点型在内存中的存储：IEEE 754标准全解析
4.1 浮点数的结构：符号位、指数位、尾数位
整数存储搞明白了，再看浮点型。C语言里的float和double遵循IEEE 754标准，这个标准把浮点数拆成三个部分：符号位、指数位、尾数位。以单精度float为例，一共32位，划分规则是1位符号位、8位指数位、23位尾数位；而双精度double一共64位，划分为1位符号位、11位指数位、52位尾数位。
这套设计和我们熟悉的"科学计数法"非常像。你在纸上把152.5写成1.525 × 10^2，这里的1是符号位正、525是尾数部分、2是指数部分。IEEE 754只是把这个思想搬到了二进制世界，并且调整了一些细节以应对二进制不能精确表达所有十进制小数的问题。
展开来说，一个规格化的IEEE 754浮点数数值等于(-1)^符号位 × 1.尾数 × 2^(指数位 - 偏置值)。这里有两个关键概念需要解释。第一个是"隐藏位"：因为规格化浮点数的尾数部分最高位永远是1，标准就干脆不存储这个1，只在读取时自动补上，这样23位尾数实际能表达24位精度。第二个是"偏置值"：单精度的偏置值是127，双精度是1023。有了偏置值，指数位才能同时表达负指数和正指数，而不需要额外的符号位。
4.2 手工推算一次：9.25和-0.75的完整存法
纸上谈兵没有意思，我们来手动把一个十进制浮点数转换成IEEE 754存储格式，拿9.25f举例。
第一步，把十进制小数转换成二进制小数。整数部分9转成二进制是1001。小数部分0.25转成二进制需要乘以2取整：0.25 × 2 = 0.5取0，0.5 × 2 = 1.0取1，所以小数部分二进制的0.25是01。合起来9.25的二进制表示就是1001.01。
第二步，规格化，也就是写成科学计数法的样子。把小数点移动到最左边第一个1的后面，1001.01变成1.00101 × 2^3。注意指数是3，这个3就是真正的指数值。
第三步，计算存储在指数位的数。单精度偏置127，所以存储指数 = 3 + 127 = 130，二进制是10000010。
第四步，填充三个字段。符号位0（正数），指数位10000010，尾数部分是去掉隐藏位1.之后剩下的00101，在后面补零到23位，变成00101000000000000000000。
拼在一起，9.25f的内存布局是：
- 符号位：0
- 指数位：10000010
- 尾数位：00101000000000000000000
组合成十六进制就是0x41140000。
再算一个负数-0.75f。0.75 = 0.5 + 0.25，二进制是0.11，规范化为1.1 × 2^(-1)。指数位存储值 = -1 + 127 = 126，二进制01111110。尾数去掉隐藏位后是1，补齐到23位是10000000000000000000000。符号位是1。拼在一起：1 01111110 10000000000000000000000，十六进制就是0xBF400000。
这两个例子做完，你会发现浮点数的存储并没有想象中那么"玄"，本质上就是一套带偏置的科学计数法。搞懂了这一层，你才能回答出面试经典题"浮点数的精度由什么决定"——答案是由尾数的位数决定，单精度23位尾数对应十进制大约7位有效数字，双精度52位尾数对应十进制大约15到16位有效数字。
4.3 为什么0.1加0.2不等于0.3
这个问题在网上几乎成了C语言入门必问。先直接说结论：不是C语言的锅，是二进制无法精确表示0.1这个十进制小数。
我帮你把0.1转换成二进制看看。用乘以2取整法算0.1：0.1 × 2 = 0.2取0，0.2 × 2 = 0.4取0，0.4 × 2 = 0.8取0，0.8 × 2 = 1.6取1，0.6 × 2 = 1.2取1，0.2 × 2 = 0.4取0，0.4 × 2 = 0.8取0……你会发现进入了循环：0.00011001100110011...，这是一个无限循环二进制小数。而float尾数只有23位，double尾数也只有52位，无论用哪种都只能存它的近似值。两个近似值相加，结果当然也只是一个近似值，不会精确等于0.3。
所以if (0.1 + 0.2 == 0.3)在大多数情况下判断为假，这不是代码逻辑错误，而是二进制表示固有的精度误差。实际开发中，浮点数做相等比较时，不要直接用==，应该判断两个数的差的绝对值是否小于某个很小的阈值，这也就是常说的相对误差或者epsilon比较法：
#include <math.h> #include <stdio.h> int double_equal(double a, double b, double eps) { return fabs(a - b) < eps; } int main(void) { if (double_equal(0.1 + 0.2, 0.3, 1e-9)) { printf("approximately equal\n"); } else { printf("not equal\n"); } return 0; }关于epsilon怎么选，给一个经验值：单精度用1e-6级别，双精度用1e-14到1e-15级别。但要注意，epsilon也分场景。如果参与比较的数非常大，比如上亿级别，那么绝对误差1e-9意义不大，应该改用相对误差比较；如果是计算物理仿真或者图形学里的判断，又需要结合实际数值范围来调整容差。别一个1e-6打天下。
4.4 特殊值：零、无穷大与NaN是怎么编码的
IEEE 754除了常规的规格化浮点数，还规定了一些特殊值。这些特殊值在C语言的调试中经常遇到，尤其当你处理非法运算时。
先看零。IEEE 754允许正零和负零同时存在，它们的符号位不同，但指数位和尾数位全为0。也就是0x00000000是+0.0f，0x80000000是-0.0f。为什么要有负零？在某些数学运算里，1除以正零等于正无穷，1除以负零等于负无穷，方向不同，物理或者工程意义上可能不同。这种差异对于科学计算软件很重要。
再看无穷大。指数位全为1、尾数位全为0，此时符号位决定是正无穷还是负无穷。正无穷对应0x7F800000，负无穷对应0xFF800000。当你做浮点运算溢出，比如把一个极大浮点数乘到上亿次，结果超出float上限时，结果就是无穷大。
最后看NaN。指数位全为1、尾数位不全为0，这个组合被定义为"不是一个数"。产生NaN的典型操作包括0除以0、无穷大减无穷大、对负数开平方等。在调试科学计算代码时，看到NaN往往说明运算链上出了非法操作，需要回头检查输入数据。
这些特殊值在C语言里的判断方式是专门函数：isnan()、isinf()、signbit()，包含在math.h头文件中。自己写x == NAN这种判断是无效的，因为NaN不等于任何数，包括它自己。
5. 实操与验证：用代码让内存老老实实"开口说话"
5.1 一段代码看遍整型和浮点型的字节布局
前面讲了一堆理论，但记忆效率最高的是自己动手看。我平时调试时常用一个技巧：把不同变量的内存按字节打印成十六进制，这样纸上推算和实际能看到的数据能够对上。
#include <stdio.h> #include <string.h> void print_bytes(const char *name, const void *p, size_t size) { const unsigned char *byte = (const unsigned char *)p; printf("%-8s: ", name); for (size_t i = 0; i < size; i++) { printf("%02X ", byte[i]); } printf("\n"); } int main(void) { int a = 5; int b = -5; unsigned int c = 300; float f = 9.25f; double d = -0.75; print_bytes("int a", &a, sizeof(a)); print_bytes("int b", &b, sizeof(b)); print_bytes("uint c", &c, sizeof(c)); print_bytes("float f", &f, sizeof(f)); print_bytes("double d", &d, sizeof(d)); return 0; }这段代码的核心是利用unsigned char *指针逐字节访问原始内存。在我这台x86小端机器上运行结果如下：
int a : 05 00 00 00 int b : FB FF FF FF uint c : 2C 01 00 00 float f : 00 00 14 41 double d : 00 00 00 00 00 00 C0 BF逐个验证一下前面的理论。a = 5是0x00000005，小端存储就是低地址到高地址05 00 00 00。b = -5的补码是0xFFFFFFFB，小端打印成FB FF FF FF，完全对得上。c = 300转十六进制简单算下，300 = 256 + 44 =0x012C，所以2C 01 00 00对应小端0x0000012C，正确。
再看浮点型。前面手工推导9.25f的存储值0x41140000，在小端机器上按字节打印就是低字节在前：00 00 14 41——因为0x41140000最低位字节是0x00，接着是0x00，再是0x14，最高位字节是0x41。至于double d = -0.75，我刚才推导的单精度版本是0xBF400000，双精度版本把它扩展为8字节，指数位和尾数位整体平移，得到0xBF F0 00 00 00 00 00 00，小端打印出来自然就是00 00 00 00 00 00 F0 BF，最后两个字节F0 BF对应大端最前面的BF F0。你拿这段代码在自己的开发环境跑一遍，看到内存原始字节后，对整型和浮点型存储的理解就会踏实很多。
注意：上面打印字节的顺序是小端机器的低地址到高地址。如果你运行在SPARC、PowerPC等大端平台上，打印顺序会完全不同。但这不影响理论验证，只要结合当前机器字节序去对齐就行。
5.2 浮点型拆字节：通过联合体直接看32位组成
如果你想把float的符号位、指数位、尾数位一个个拆出来看，除了用指针强转，C语言里更简洁优雅的是联合体方式：
#include <stdio.h> #include <stdint.h> typedef union { float fval; uint32_t uval; } float_bits; int main(void) { float_bits fb; fb.fval = 9.25f; uint32_t sign = (fb.uval >> 31) & 0x1; uint32_t exp = (fb.uval >> 23) & 0xFF; uint32_t frac = fb.uval & 0x7FFFFF; printf("fval = %f\n", fb.fval); printf("hex = 0x%08X\n", fb.uval); printf("sign = %u\n", sign); printf("exp = %u (real exp = %d)\n", exp, (int)exp - 127); printf("frac = 0x%06X\n", frac); return 0; }联合体在这里的原理是：fval和uval共享同一块四字节内存，你把数据当float写进去，再去当uint32_t读出来，就能拿到位模式。这是C语言中一种完全合法且可移植性较好的"reinterpret"手段，比用指针强制转换再拷贝字节要直观得多。需要特别说明的是，C语言标准中对通过union的不同成员访问同一内存这种行为有明确定义，主流编译器都支持得很好，属于实用技巧而不是"未定义行为"。
当你看到9.25f跑出来的输出是sign = 0、exp = 130、frac = 0x140000，再对照我前面手动推算的结果，那种"理论终于落地"的感觉，比你盯着教科书硬记一整天都要管用。
6. 常见问题与排查技巧实录
6.1 整型溢出报警：是编译器坑你还是你坑了自己
有符号整型溢出我再说一次，是未定义行为。什么叫未定义行为？就是C标准压根不管结果是多少，编译器可以自由发挥。常见的结果有两种：低优化模式可能回绕成负数，高优化模式可能直接把整个表达式优化成"看似不合理的常量"。比如int x = INT_MAX; x + 1;，在开启-O2优化后，编译器可能推断这个加法根本不会执行到，干脆把后续代码剔除。这在线上排查时非常难定位。
无符号整型则是定义好的模运算回绕，所以如果你做计数器、哈希值、环形缓冲区索引，请明确用uint32_t、uint64_t等无符号类型。还有一个实战技巧：判断两个无符号整数相加是否会溢出，可以改用条件判断，不要傻傻加完再检查，因为加完那一步就已经回绕了。
#include <stdint.h> #include <stdio.h> int will_add_overflow_uint32(uint32_t a, uint32_t b) { return a > UINT32_MAX - b; } int main(void) { uint32_t big = 4000000000u; uint32_t x = 500000000u; uint32_t y = 600000000u; printf("%d\n", will_add_overflow_uint32(big, x)); // 0 printf("%d\n", will_add_overflow_uint32(big, y)); // 1 return 0; }如果你发现自己代码里出现大量"加完判断反而进位丢失"或者"乘以较大数变成负数，换unsigned之后又变成超大正数"的现象，不用怀疑，先检查运算数类型和是否有符号，这大概率就是整型溢出或者符号搞混造成的。
6.2 浮点数的比较与打印：默认精度会骗你
浮点型相关的问题，第二大高发区就是打印和比较。
打印方面，printf("%f", f)默认打印小数点后6位。这不代表浮点数本身存储的精度就是6位，只是默认显示格式。如果你用%.10f打印0.1f，会看到输出0.1000000015，这个尾巴不是bug，而是double在把float提升到double后再打印时揭示了单精度存储的近似误差。想临时查看一个浮点数的完整位模式，最可靠的办法是直接打印十六进制整数形式，比如printf("0x%08X\n", *(unsigned int *)&f)，它能让你直接看到原始存储值。
#include <stdio.h> int main(void) { float f = 0.1f; double d = 0.1; printf("float 0.1f = %.10f\n", f); printf("double 0.1 = %.10f\n", d); printf("float hex = 0x%08X\n", *(unsigned int *)&f); printf("double hex = 0x%016llX\n", *(unsigned long long *)&d); return 0; }比较方面，除了之前说的epsilon法，另一个思路是避免对浮点数直接判等，改用固定缩放后的整数比较。比如金额计算，用单位转换成分再转成整型，这在财务系统里是很常见的做法。比如3.14元可以改成314分，用int存储。
6.3 大小端搞反的典型表现：读出的整数数值完全不对
如果做二进制协议解析时出现"每个字段都能读到，但数值完全是天文数字"的情况，优先怀疑大小端转换。一个典型场景是把四字节的大端数值直接memcpy到一个本地int再输出，在x86小端环境下读出的值会变成字节反向后的一个巨大数。
排查手段其实很简单。先取一个固定已知数，比如协议文档定义某个字段等于0x01020304，你这边读出来如果是0x04030201，妥妥大小端反了，统一换成ntohl转换就好。还有一种隐蔽场景是在结构体里直接声明了一个uint32_t，然后从文件流fread整块读取。文件里如果是大端数据，你这样直接读出来的结构体成员数值必然错乱，因为内存布局和文件里字节排列没有做转换。对这种固定二进制格式，我强烈建议按字节读取后用移位手动拼接，而不是直接读进结构体。
6.4 调试内存时的几条实用心得
最后分享几个我自己长期调试C语言程序时沉淀下来的经验。
第一，观察内存时永远先确认"当前平台字节序"。同样的十六进制序列在小端和大端机器上完全是两回事。可以在调试会话开始前先跑那段检测大小端的代码，免得对着内存窗口分析半天方向反了。
第二，区分"内存显示"和"逻辑值"。内存窗口按十六进制显示时，看到01 00 00 00，它可能是小端存储的整数1，也可能是某个四字节结构体的第一个成员变量为1。不要看到字节序列就急着下结论，先搞清楚这个变量在代码里的类型和含义。
第三，做位运算拆解时，小心隐式整型提升。uint32_t做移位运算时，如果右侧参与运算的表达式里有signed int或int，可能会发生符号扩展，导致最终结果和预期完全不同。比如(uint32_t)(-1) >> 1与(-1 >> 1)结果就不一样：前者是0x7FFFFFFF，后者在某些编译器上可能是0xFFFFFFFF。
第四，利用sizeof和_Static_assert在编译期检查你认为的类型大小。跨平台开发中，int并不是固定4字节，而是"至少2字节、通常4字节"。如果你依赖固定字节宽度，请显式使用int32_t、uint64_t、float、double这些stdint.h中的定宽类型，再配合_Static_assert(sizeof(int32_t) == 4, "int32_t must be 4 bytes")，能在编译期提前发现问题。
我做C语言教学和调试这些年，最深的体会就是：内存存储这件事，看书觉得自己懂了不算懂，能推算出十六进制、能在调试器里验证、能在出问题时快速定位，才算真懂。整型和浮点型这两大基础数据类型的存储，其实是理解指针、结构体、文件IO、网络协议的基石。你花一个下午把这里的代码全部亲手跑一遍，把每一个输出都对照着推算一遍，之后遇到任何二进制层面的诡异问题，心里都会比之前有底得多。
