简介：固定宽度整数类型是跨平台 C 编程中避免隐式位宽差异的关键，这份资料面向需要编写可移植代码的 C 开发者，聚焦 stdint.h 与 inttypes.h 两个标准头文件，技能层级覆盖从初学 C99 整数类型体系到进阶跨平台开发的读者。内容涵盖 int8_t/int16_t/int32_t/int64_t 及对应无符号类型，也整理 int_least*_t、int_fast*_t、intmax_t 等扩展类型的选择逻辑，并解释 PRIu64、PRId32 等格式宏在 printf/scanf 中的正确用法，能避开不同平台 int、long 位宽不一致引发的编译错误或运行时问题。压缩包共 2 个 h 类型文件，整体约 5KB，轻量便于直接对照引用；两个文件分别承担定宽类型定义与格式化输入输出接口，结构简单但实用性强。已有 4444 人学习下载，对于需要处理网络协议、二进制文件解析、嵌入式底层开发或追求代码清晰度的读者，是一份可直接嵌入项目的精简参考。
1. stdint.h到底是什么：一个让整数“尺寸”统一的神奇头文件
如果你写过C语言，一定见过这样的困惑：同样是int，在某台机器上是32位，在另一台老式嵌入式开发板上却只有16位。这就像你去五金店买一颗标着“4号”的螺丝，有的店卖的是4毫米，有的店卖的是4分，装上去不是松就是滑。C语言里的int，就是这颗尺寸不统一的螺丝。
stdint.h是C语言标准库里的一个头文件，名字是“standard integer”的缩写，它干的事情很纯粹：把整数类型的“尺寸”明确地固定下来。你不再写暧昧不清的int，而是直接写int32_t、uint64_t这类类型，不管换到什么平台，它都保证是32位、保证是64位。为什么值得搞懂它？因为跨平台开发和数据通信时，整数一旦偷偷变短，轻则打印乱码，重则数据溢出、程序崩溃，而且这种问题最难排查。提前认识stdint.h，就是提前踩住这个雷。
2. 为什么需要stdint.h：从“int到底多大”说起
2.1 一个翻车现场：同样的代码，换个平台就坏了
某开发者曾经在某个嵌入式项目里写过一段代码，用int保存传感器返回的计数值，在自己手上的32位开发板上跑得稳稳当当。后来项目移植到另一块16位的开发板上，一切直接乱套：计数值超过32767就变成负数，日志里出现一堆莫名其妙的溢出数据，程序偶尔还会死循环。
排查了很久，最后定位到原因：int在那个16位环境里只有16位，最大只能存32767。代码没有错，错的是“用了一个大小不确定的类型”。这就是C语言历史包袱的典型场景——int的位数从来不是一个固定值，而是“由编译器决定”，跨平台就意味着冒险。
2.2 C标准当年为什么留这个口子
C语言诞生于上世纪70年代，那时处理器从8位到32位都有，为了让编译器能贴近硬件、跑得更快，标准没有把short、int、long的位数组死，只给了一个“最低保证”：
| 类型 | C标准最低保证 | 常见的16位环境 | 常见的32位环境 | 常见的64位环境 |
|---|---|---|---|---|
short | 至少16位 | 16位 | 16位 | 16位 |
int | 至少16位 | 16位 | 32位 | 32位 |
long | 至少32位 | 32位 | 32位 | 64位（部分环境） |
表格里的“最低保证”意思是：写int，你只知道它“至少16位”，具体是16位还是32位，要等编译那一刻才揭晓。你写的是一行代码，编译器却可能给你两种完全不同位数的整数。这不叫bug，这叫“实现定义行为”，而实现定义行为是跨平台代码的第一大坑。
2.3 解决思路：用typedef给类型起一个固定的别名
stdint.h破解难题的办法笨但有效：typedef。它在底层做了一堆类型重命名，例如在32位环境里typedef int int32_t;，在64位环境里typedef long int32_t;。用户代码完全不关心int32_t背后是int还是long，只要把它当作“恰好32位的有符号整数”使用即可。
/* 在某个32位环境中，stdint.h内部大概是这样的： */ typedef signed int int32_t; typedef unsigned int uint32_t; /* 在某个64位环境中，同样的int32_t可能长这样： */ typedef signed int int32_t; /* 64位环境下int通常仍是32位 */ typedef unsigned long uint64_t; /* long在64位下就是64位 */关键点在于：你写的业务代码永远只用int32_t、uint64_t这些名字，适配平台这件事由头文件代劳。同时stdint.h还配套定义了INT32_MIN、INT32_MAX、UINT64_MAX这些边界宏，写范围检查时不用自己背数字。这就是stdint.h存在的全部理由：给整型戴上“固定尺寸”的枷锁，换平台时不再担惊受怕。
3. stdint.h里到底装了什么：一套完整的整数类型家族
3.1 精确宽度类型：int8_t、int16_t、int32_t、int64_t
stdint.h最核心的成员是“精确宽度整数类型”，也就是int8_t、int16_t、int32_t、int64_t，以及它们对应的无符号版本uint8_t、uint16_t、uint32_t、uint64_t。
所谓“精确宽度”，指的是这种类型一经存在，就是“恰好N位”，不会多也不会少。你声明了一个uint32_t的变量，它就是32位，在任何平台、任何编译器下都成立。这种确定性在跟硬件打交道时极其重要，比如一个网络协议的报文长度字段固定是4字节，你自然用uint32_t描述它，序列化、反序列化时不会产生偏差。
#include <stdint.h> uint32_t frame_len = 4096; int64_t total_bytes = 0; total_bytes += frame_len; /* 这里永远不会因为int太短而溢出 */注意一个细节：int8_t只在“一个字节恰好8位”的环境里存在。绝大多数现代平台都满足，但在少数CHAR_BIT不是8的特殊DSP上，int8_t会被省略，代码里如果用了它就会编译失败。这是精确宽度类型的代价——“保证位数的前提是它存在”。
3.2 最小宽度类型：int_least8_t、int_least16_t……
精确宽度类型不一定处处都有，而且有时“恰好32位”可能有点浪费。stdint.h为此又准备了“最小宽度类型”：int_least8_t、int_least16_t、int_least32_t、int_least64_t，以及对应的无符号版本。
“least”的意思是：保证类型至少有N位，同时选择“能装下又不浪费”的最小尺寸。例如你要存一个传感器数值，至少需要16位，那么用int_least16_t。在8位单片机上它是16位，在64位工作站上它仍然是16位，不会因为平台变宽就自动膨胀。这样既保证了下限，又控制了内存开销。写数组、存大量结构体时，least类型往往比精确宽度类型更合适。
3.3 最快宽度类型：int_fast8_t、int_fast16_t……
与least相对的是“最快宽度类型”：int_fast8_t、int_fast16_t、int_fast32_t、int_fast64_t。它的语义是：保证至少有N位，但底层选用“当前CPU算术运算最快”的类型。
一个典型的例子：在64位环境里，int_fast8_t很可能被定义成64位整数，因为64位加减乘除在CPU里一次就能完成，而8位或16位运算反而需要额外的对齐和扩展操作。所以频繁进行算术运算的计数器、累加器，用int_fast32_t这类类型，性能比用int32_t更好。代价是它占内存更多，千万别拿fast类型去存大型数组，否则缓存会被撑爆。
3.4 能装下一切的intmax_t，和专为指针准备的intptr_t
stdint.h还定义了“最大宽度整数类型”intmax_t和uintmax_t。它们能装下环境中任意一种整数类型，相当于整型世界的“通用容器”。当你需要把一个整数值传递给可变参数函数、或者做某种通用的数值转换时，intmax_t最不容易出错。
另外两个常用成员是intptr_t和uintptr_t，它们表示“能完整装下一个指针的整数类型”。在64位环境里，指针是64位，uintptr_t就定义成64位无符号整数。做指针与整数互转（比如把地址数值化打印、对齐计算）时，它们是唯一靠谱的选择。注意intptr_t在C标准里被标为可选类型，绝大多数现代平台都有，但研究代码可移植性时要留个心眼。
3.5 限制宏与字面量宏：INT32_MAX、UINT64_C这些怎么用
除了类型，stdint.h还提供了一组限制宏和字面量宏。
限制宏包括INT8_MIN、INT32_MAX、UINT64_MAX等，直接给你每个类型能表示的边界。写范围检查时不需要自己算“2的31次方减1是多少”，直接引用宏，代码又好读又不易错。
字面量宏则是INT32_C(100)、UINT64_C(1000)这种。它们的作用是把普通整数字面量“强制”转换成对应类型的宽度，防止参与运算时被隐式提升成错误的位数。
#include <stdint.h> if (value > UINT32_MAX) { /* 超过32位无符号上限，直接报错 */ } uint64_t big = UINT64_C(1) << 40; /* 没有UINT64_C，1会被当成32位int，移位直接溢出 */UINT64_C(1)展开后相当于1ULL，有了它，左移40位才能得到正确结果。stdint.h提供的不是几个孤零零的类型，而是一整套“固定尺寸整数”的配套工具，从类型、边界到字面量全都有。
4. inttypes.h：stdint.h的最佳搭档，解决printf的格式串难题
4.1 一个隐蔽的坑：打印int64_t时%ld可能出错
类型定下来了，新的问题又来了：怎么把int64_t打印出来？
很多人的第一反应是“64位嘛，用%ld”。这个习惯大错特错。int64_t在64位环境里底层可能是long，在另一个32位环境里底层则可能是long long。编译器不知道它背后是谁，只看到你的格式串和实参类型不匹配，于是行为变成“未定义”——有时打印出正确数字，有时打印出乱码，全看运气。
某开发者就栽过一次：他在一个跨平台项目里用%lu打印uint64_t，在原来环境里正常，代码换到另一个64位环境后，日志里出现一个巨大的离谱数字。排查到最后，发现就是格式串的问题，跟业务逻辑毫无关系。这种问题不用stdint.h根本发现不了，因为它在某个平台上一直是“恰好能跑”。
4.2 解法：PRIu64、PRId32这些格式宏
inttypes.h就是为了解决格式串难题而生的，它定义了一组形如PRId32、PRIu64、PRIx32的宏，展开后恰好是对应类型所用的printf转换说明。
#include <inttypes.h> #include <stdio.h> uint64_t file_size = 1024 * 1024 * 1024; printf("size = %" PRIu64 "\n", file_size); /* 自动展开成%llu或%lu */ int32_t code = -100; printf("code = %" PRId32 "\n", code); /* 自动展开成%d或%ld */注意写法：PRIu64前面要加一个%，因为宏展开的内容是llu或lu这种“转换说明的后半截”，拼起来才是完整的%llu格式串。上面的代码里，PRIu64在某个64位环境中展开为lu，在另一个环境中展开为llu，无论哪种，最终格式串都和uint64_t的真实类型匹配。
inttypes.h的宏分两套：一套给printf，前缀是PRI；一套给scanf，前缀是SCN。常用对应关系如下：
| stdint.h类型 | printf格式宏 | scanf格式宏 |
|---|---|---|
int32_t | PRId32 | SCNd32 |
uint64_t | PRIu64 | SCNu64 |
uint32_t | PRIx32（十六进制） | SCNx32 |
intmax_t | PRIdMAX | SCNdMAX |
4.3 别小看inttypes.h：它还有strtoimax和strtoumax
除了格式宏，inttypes.h还附带一组处理最大整数类型的函数：strtoimax和strtoumax，作用是把字符串解析成intmax_t和uintmax_t。它们像更安全的strtol、strtoull，但返回值统一落到最大整数类型上，不会因为long位数不同而截断。
#include <inttypes.h> #include <stdio.h> const char *text = "18446744073709551615"; char *endptr = NULL; uintmax_t val = strtoumax(text, &endptr, 10); /* 支持任意平台的最大无符号整数 */写配置文件解析、文本转数值这类通用代码时，strtoimax/strtoumax能省掉大量“根据平台判断用哪个函数”的条件编译。inttypes.h和stdint.h相辅相成：一个管类型，一个管读写和打印，少一个都会难受。
5. 常见误区：这些跟stdint.h易混的类型到底怎么分
5.1 int32_t和int不是一回事
易混点：在绝大多数32位平台上，int32_t的底层就是int，于是有人觉得“那我直接用int多方便，何必绕一圈”。
为什么混：因为两者在同一个环境下确实大小相同、数值范围相同，赋值兼容没有任何警告。
怎么区分：int的位宽由平台决定，这是它的本质；int32_t则是一个“承诺”，承诺无论如何都是恰好32位。打个比方，int像房东临时给的钥匙，可能通用也可能随时换；int32_t是你自己配的钥匙，锁死了32扇门。只要项目有可能换平台，用int替代int32_t就是给自己埋雷，今天能跑不代表明天能跑。
5.2 uintptr_t和size_t都表示非负整数，能互相用吗
易混点：size_t是sizeof运算符返回的类型，uintptr_t是能装下指针的无符号整数，两个都是无符号、在64位平台上都是64位，看起来差不多。
为什么混：数值上它们经常互相赋值，而且编译器不报错，于是有人顺手混用。
怎么区分：语义完全不同。size_t表达的是“对象的大小”，来自sizeof；uintptr_t表达的是“指针的数值表示”，服务于指针和整数互转。把size_t当成uintptr_t用，等于拿一个表示“长度”的整数去存储“地址”，一旦指针尺寸和对象大小不一致，高位的地址信息就可能被截断。实践中：算偏移、开缓冲区用size_t；把指针转成整数打印或对齐，用uintptr_t，别混。
5.3 int64_t在32位平台上能用吗
易混点：有人以为int64_t只在64位平台存在，到了32位平台就没有、不能用。
为什么混：因为“64位平台”和“64位类型”这两个概念被绑在了一起，想当然认为缺一不可。
怎么区分：int64_t在C标准里被标记为“可选”，但当代几乎所有的32位编译器都提供了它。能用，只是代价不同：32位CPU没有64位寄存器，一次64位加法要拆成多条指令完成，运算慢一些。所以结论是：通信协议、文件格式里需要64位字段，照用int64_t没问题；但如果是性能敏感的循环计数器，尽量改用int32_t或int_fast32_t，没必要让每条指令都背着重担跑。
5.4 least和fast怎么选
易混点：int_least16_t和int_fast16_t名字长得像，都保证“至少16位”，于是有人以为随便选哪个都一样。
为什么混：标准文档里描述它们时都用“至少N位”，措辞几乎相同，初学者很容易忽略后面的“least=内存最小，fast=速度最快”。
怎么区分：做数据存储——数组、结构体、协议缓冲，优先int_leastN_t，因为省内存；做算术运算——累加、乘法、循环变量，优先int_fastN_t，因为用原生字长。如果规则必须“恰好N位”，比如二进制协议里的字段，那least和fast都不够格，只能上intN_t，least只保证“至少”，不保证“恰好”，这个区别是关键。
5.5 打印无符号整数用%u就够了？
易混点：uint32_t在32位平台上底层就是unsigned int，很多人觉得那打印用%u天经地义。
为什么混：因为确实在很多环境里%u能用，偶尔换平台也没报错，就形成了路径依赖。
怎么区分：一旦遇到uint64_t，%u立刻翻车，因为uint64_t底层是unsigned long long或unsigned long，%u期望的却是unsigned int，实参类型和格式串不匹配，轻则打出奇怪数字，重则读错参数造成未定义行为。另外uint16_t在传给可变参数函数时会被整数提升成int，这时%u也不匹配。别再靠感觉猜测，统一用PRIu16、PRIu64这类宏，编译器会在格式串不匹配时给你warning，而这个warning恰恰是帮你抓bug的好朋友。
6. 什么时候用、什么时候别用：我把类型写死的选择标准
6.1 必须用stdint.h的场景
第一类是二进制协议和文件格式。协议字段的位宽是双方约定好的，收发双方可能跑在不同的平台上，发送端用uint32_t表示长度字段，接收端也得用uint32_t解析，换任何平台都不允许变成别的宽度。这里不用stdint.h，协议就没法做。
第二类是嵌入式开发和寄存器操作。硬件寄存器就是固定位数的，比如某个控制寄存器恰好32位，用uint32_t来描述天经地义。某开发者做过一个单片机项目，寄存器操作全部用uint32_t，后来把代码迁移到另一个厂商的芯片上，几乎零修改。
第三类是跨平台库的内部实现。一个库的算法结果不能因为宿主平台不同而变化，内部整数统一用固定宽度类型，能保证同样的输入产生同样的输出。某跨平台系统的核心排序模块就是用int32_t做主键类型，换平台后排序结果完全一致。
/* 一个典型的跨平台通信协议结构体 */ typedef struct { uint32_t magic; /* 固定魔数，永远是0xA1B2C3D4 */ uint16_t version; /* 协议版本号 */ uint32_t payload_len; /* 数据长度，不因平台变化 */ uint8_t crc8; /* 校验字段 */ } packet_header_t;这个结构体在任何平台上都是恰好13字节，打包解析不会出现错位。
6.2 别硬上stdint.h的场景
第一类是纯本机的临时脚本。程序只在自己一台机器上跑，不会移植，int在本地已经足够，写int32_t虽没错但略显多余。第二类是已经对外发布的API参数。把一个库的公开函数参数从int改成int32_t，看似等价，实际上可能改变ABI，破坏已有调用方的二进制兼容，属于伤筋动骨。没有跨平台需求时，保持原状更稳妥。第三类是要兼容非常老旧的编译器——C99标准之前还没有stdint.h，那只能自己用宏包一层别名，不能强制要求老工具链支持新头文件。
6.3 我的“血泪经验”和自查清单
某开发者第一次因为int翻车，是在一个图像处理Demo里。他用int存图像的色值累加结果，在一台设备上图像正常，换到另一台设备后画面整体变暗，加的颜色值动不动变成负数。当时调了半天，最后把关键字段全部换成int32_t和uint32_t，问题立刻消失。从那以后，我每次写涉及数据格式的代码，都强制走一遍自查：结构体每个字段用的是精确宽度、least还是fast；每个打印语句有没有配对应的PRI宏；有没有把size_t和uintptr_t混在一起。这套流程看着繁琐，但真的能拦住大多数“换个环境就崩”的问题。希望帮到你。
本文还有配套的精品资源，点击获取
