16位与32位整数的有符号-无符号加法转换为何存在差异？
这个差异完全是由C++标准定义的整数提升和寻常算术转换规则导致的，并不是编译器的“特殊处理”——你在GCC、Clang多个版本和不同Linux发行版上得到一致结果，恰恰说明所有合规编译器都在严格遵循标准行为。
让我们逐个拆解两种场景的执行逻辑：
16位操作数场景：uint16_t(2) + int16_t(-3)
在几乎所有现代平台上，int类型的宽度是32位（比uint16_t/int16_t的16位宽），而且int的取值范围（-231到231-1）完全覆盖了uint16_t的所有值（0到65535）。根据C++的整数提升规则：
- 所有宽度小于
int的整数类型，都会被自动提升为int类型参与运算。
所以uint16_t(2)会被提升为int类型的2，int16_t(-3)会被提升为int类型的-3。两者相加的结果是int类型的-1，直接输出就是-1。
32位操作数场景：uint32_t(2) + int32_t(-3)
此时uint32_t和int32_t的宽度都是32位，和平台上int的宽度一致。根据C++的寻常算术转换规则：
- 当有符号类型和无符号类型的“秩”相同（简单说就是宽度相同）时，会检查有符号类型能否容纳无符号类型的所有值。
int32_t的最大值是231-1，显然装不下`uint32_t`的最大值232-1，因此两个操作数都会被转换为无符号类型。
所以int32_t(-3)会被转换为uint32_t类型的4294967293（这是-3在无符号32位下的二进制表示对应的十进制值），加上uint32_t(2)后得到4294967295——也就是无符号32位下等同于-1的数值，输出时自然显示这个无符号值。
关于行为的一致性
这种转换行为是由C++标准严格规定的，只要编译器遵循C++标准（你测试的GCC、Clang都属于这类），在相同的平台（即int宽度相同的平台）上，结果就会完全一致。
唯一的例外是如果某个平台的int是16位（现在几乎不存在这样的平台），那16位场景的结果会和32位场景一致——因为此时int无法容纳uint16_t的所有值，操作数会被转换为无符号类型，结果会显示65535而不是-1。但在现代主流平台（x86、x86_64、ARM等）上，int都是32位，所以你看到的结果会是普遍一致的。
内容的提问来源于stack exchange，提问作者Nikolaj
