short i/o易错因类型不匹配：cin/cout自动适配，但printf需%hd；short非精确16位，跨平台应选int16_t；数组存short仅大量连续时省内存；int转short溢出是未定义行为。
为什么 short 读入或输出时经常出错？
因为 short 不是 int 的“缩写版”，I/O 流默认按 int 处理，直接用 cin >> s（s 是 short）看似能跑，但底层可能触发隐式提升，导致高位截断或符号扩展异常；printf 更危险——%d 对应 int，传 short* 就是未定义行为。
- 用
cin/cout时，确保变量声明为short即可，流会自动适配（但别混用scanf/printf） - 用 C 风格 I/O 时，必须显式转换：
printf("%hd", s)（%hd才对应short），scanf("%hd", &s) - 若从文件或网络读二进制数据，
short的字节序和对齐必须和源一致，否则直接memcpy过去会错位
short 和 int16_t 到底能不能互换？
不能无条件互换。虽然多数平台下 short 是 16 位有符号整数，但 C++ 标准只要求它 ≥16 位（常见实现确实是 16 位），而 int16_t 是精确 16 位的固定宽度类型，来自 <cstdint></cstdint>。
- 跨平台通信、协议解析、内存映射结构体中，必须用
int16_t，避免short在某些嵌入式平台是 32 位的风险 - 函数参数或模板推导中，
short和int16_t是不同类型，哪怕值域相同，也不能隐式转换（尤其在重载或 SFINAE 场景） - sizeof(
short) == sizeof(int16_t) 仅在int16_t存在时成立；若平台不提供int16_t（极少见），编译会失败
数组里存 short 真的节省内存吗？
只在大量连续存储且对缓存敏感时才明显；单个变量或小数组几乎没差别，还可能因对齐反而更占空间。
- 结构体中混用
short和int，编译器可能插入填充字节，实际内存占用未必减少（比如struct { short a; int b; }通常占 8 字节而非 6） - 现代 CPU 缓存行是 64 字节，用
short数组能让更多元素落入同一缓存行，批量计算时吞吐更高 - 但若频繁做算术运算，
short会被提升为int再计算，中间多一次零扩展/符号扩展，反而增加指令开销
把 int 强转成 short 为什么会静默溢出？
因为 C++ 标准规定：有符号整数溢出是未定义行为（UB），编译器不保证报错，也不保证截断；实际表现取决于编译器、优化等级和目标架构。
立即学习“C++免费学习笔记（深入）”；
- Clang/GCC 在
-fsanitize=undefined下会捕获运行时报错；但发布版通常关掉，溢出后值不可预测（不是简单取低 16 位） - 安全做法是先检查范围：
if (x >= -32768 && x (x); - 若确定要截断（如音频采样），用无符号中间类型更可控：
s = static_cast<short>(static_cast<uint16_t>(x) & 0xFFFF)</uint16_t></short>，但要注意符号位含义
最麻烦的是，这种溢出往往只在特定输入下触发，测试容易漏，上线后突然崩——所以只要逻辑上可能越界，就别依赖“看起来没出事”。
