short是有符号类型，范围通常为−32,768～32,767；unsigned short是无符号类型，范围为0～65,535；二者均至少16位，现代平台多为恰好16位；使用时需注意格式符、隐式转换、整型提升及跨平台兼容性。
short 是有符号的，unsigned short 是无符号的
这是最根本的区别：short 能表示负数，范围通常是 −32,768 到 32,767；unsigned short 只能表示非负数，范围是 0 到 65,535。标准只要求两者至少占 16 位，但实际在几乎所有现代平台（x86/x64/ARM）上都是恰好 16 位。
常见错误现象：short x = -1; printf("%u", x); 输出 huge 正数（比如 65535），因为用 %u 强行解释有符号值的位模式，不是类型转换。
- 别靠
sizeof(short)假设它是 16 位——虽然几乎总是，但 C++ 标准只保证 ≥16 位 - 如果需要确定宽度，优先用
int16_t/uint16_t（需#include <cstdint></cstdint>） -
short和unsigned short之间赋值会隐式转换，但负值转unsigned short会绕回（如 −1 → 65535），不是截断也不是报错
函数参数和模板推导中容易意外丢失符号性
当把 short 传给接受 int 的函数（比如 printf、std::max），它会先整型提升为 int；但 unsigned short 提升为 unsigned int。这在泛型代码里可能引发静默行为差异。
使用场景：写一个通用比较函数模板时，std::max<short>(a, b)</short> 和 std::max<unsigned short>(a, b)</unsigned> 行为一致，但若模板内部用了 > 和负数混合运算，结果就取决于你传的是哪个类型。
立即学习“C++免费学习笔记（深入）”；
- 打印时务必匹配格式符：
short用%hd，unsigned short用%hu（%d或%u会出错） - 用
auto推导时，auto x = short{1};得到short，但auto y = x + 1;得到int（整型提升） - 序列化或网络传输时，别假设
short和unsigned short的内存布局“只是符号位不同”——它们是独立类型，ABI 可能对齐不同
与 char 混用时符号性会传染
char 在不同编译器下默认可能是有符号或无符号（取决于平台和编译选项），而 short 总是有符号、unsigned short 总是无符号。但一旦你把 char 和 short 一起算术运算，符号性会影响结果。
常见错误现象：char c = -1; short s = c + 1; 看似简单，但 c 提升为 int 后是 −1，加 1 得 0；而 unsigned char uc = 255; unsigned short us = uc + 1; 得到 256 —— 两者数值路径完全不同。
- 避免直接用
char和short混合计算；明确需要字节语义时，用signed char或unsigned char - 读二进制数据到
short*时，确保源数据确实是按有符号 16 位小端/大端存的；否则用uint16_t读再手动符号扩展 - Clang/GCC 的
-fsigned-char或-funsigned-char会影响char默认符号性，但对short无影响
性能和 ABI 兼容性基本没差别
在 x86-64 或 ARM64 上，short 和 unsigned short 的加载、比较、存储指令完全一样；编译器生成的汇编通常无法区分二者，区别只在语义和常量折叠阶段。
真正影响性能的地方反而是：你为了“省空间”用 short 存数组，结果 CPU 访问时因未对齐或需要掩码操作，反而变慢——现代 CPU 对 32 位访问最友好。
- 结构体里混用
short和unsigned short不会增加大小，但可能改变字段偏移（因对齐规则相同，一般无影响） - 跨平台 DLL 或 SO 接口里暴露
short类型要小心：Windows 和 Linux ABI 都定义了它，但嵌入式平台可能不一致 - 别为了“看起来更精确”在 API 中暴露
unsigned short表示长度——size_t或std::size_t才是正解
最麻烦的其实是人：看到 unsigned short 就默认“这个值不会超 65535”，但没人检查上游是否真做了约束；等某天输入超过 65535，它就静默绕回成一个小正数，bug 很难复现。
