int宽度不固定而uint32_t严格保证32位无符号：前者依赖平台，后者由定义且跨平台一致，涉及协议、硬件或二进制序列化时必须用uint32_t。
int 不保证是 32 位，uint32_t 才保证
这是最核心的区别：int 的宽度由编译器和平台决定，常见是 32 位，但在某些嵌入式平台或旧系统上可能是 16 位；而 uint32_t 是 C++11 引入的固定宽度类型，**只要标准库支持，它就一定是无符号 32 位整数**。
实际开发中，如果你依赖“恰好 32 位”（比如解析网络协议、内存映射寄存器、与硬件交互），用 int 就可能出错——sizeof(int) 在 Windows x64 和 Linux x86_64 都是 4，但理论上不保底；而 sizeof(uint32_t) 永远是 4，且定义在 <cstdint></cstdint> 中。
- 别在二进制序列化或跨平台通信中用
int存长度/偏移/标志位 -
uint32_t要求平台提供该类型，若不可用（极少见），std::uint32_t会未定义，编译失败——这反而是好事，比运行时溢出强 - 注意：没有
uint32_t不代表没 32 位整数，只是没“标准命名”，此时可用unsigned long或unsigned int，但必须加static_assert校验宽度
符号性差异直接导致行为分叉
int 是有符号类型，uint32_t 是无符号类型。这不是“写法不同”，而是底层运算逻辑不同——尤其在比较、隐式转换、位移时容易翻车。
典型错误现象：if (x 对 <code>uint32_t x = 0xFFFFFFFF 永远为假；uint32_t a = 1, b = 2; auto c = a - b; 得到极大正数而非 -1。
立即学习“C++免费学习笔记（深入）”；
- 混合运算时，
int会先提升为unsigned再算（C++ 整型提升规则），比如int i = -1; uint32_t u = 1; bool t = i 实际比较的是 <code>0xFFFFFFFFU → false - 循环计数器用
uint32_t时，for (uint32_t i = n; i >= 0; --i)是死循环（下溢后变大） - 函数参数若声明为
int却传入uint32_t，可能触发警告（如 GCC 的-Wsign-conversion），但不会报错
何时该选 uint32_t 而不是 int
关键看语义和约束：你是否需要“明确 32 位宽度”或“严格非负”？如果只是临时计数、数组索引、小范围中间变量，int 更自然；如果涉及协议字段、哈希值、时间戳低 32 位、位掩码操作，优先 uint32_t。
- POSIX 系统调用返回值常用
ssize_t，但参数如read(fd, buf, count)的count是size_t—— 这里不用uint32_t，因为大小可能超 4GB - OpenGL / Vulkan API 大量使用
uint32_t表示对象句柄、枚举值、尺寸，因需跨平台对齐且无符号更安全 - STL 容器的
size()返回size_t，不是uint32_t；强行转可能截断（64 位系统上size_t是 64 位）
兼容性和头文件陷阱
uint32_t 不是关键字，是 typedef 别名，定义在 <cstdint></cstdint>（C++）或 <stdint.h></stdint.h>（C）。漏包含头文件会导致编译错误；而 int 是内置类型，无需头文件。
- Windows MSVC 早期版本（如 VS2010）默认不启用 C++11，需手动开
/std:c++11或更高，否则uint32_t不可见 - 某些裸机环境（如 FreeRTOS、Zephyr）可能没完整
<cstdint></cstdint>，这时要查 SDK 是否提供等效定义（如__UINT32_TYPE__宏） - 别用
using u32 = uint32_t;然后全局 typedef——不同模块若各自定义，可能冲突；统一用std::uint32_t或包含标准头后直接用
真正麻烦的从来不是选哪个类型，而是同一份代码里混用又不加校验。比如结构体里一半 int 一半 uint32_t，再加个位域，对齐和符号扩展就很容易吃暗亏。
