short加减法悄无声息出错是因为有符号溢出导致回绕，c++不检查不报错；如32767+1得−32768；根本原因是运算先提升为int再截断回short；安全做法是提前用numeric_limits检查或全程用int计算后断言转换。
short 类型加减法为什么会悄无声息地出错
因为 short 是有符号整型，典型范围是 −32768 到 32767（16 位），超出就溢出，而 C++ 默认不检查、不报错、不抛异常——结果直接回绕。比如 32767 + 1 变成 −32768，编译器连警告都不一定给。
常见错误现象：short a = 32767; short b = 1; short c = a + b; 看似合法，但 c 的值是 −32768，不是 32768。这不是 bug，是标准行为。
- 根本原因：C++ 中算术运算会先将
short提升为int，但赋值回short时会截断——截断即溢出 - 使用场景：嵌入式通信协议字段、内存敏感结构体、旧接口兼容层，这些地方才真需要
short；日常计算别硬用 - 编译器差异：GCC/Clang 在
-Wall下对常量溢出可能报警，但对运行时变量几乎不提示；MSVC 更沉默
怎么安全地做 short 加减（不靠运气）
核心原则：别让溢出结果落回 short。要么提前检查，要么全程用更大类型运算，最后再谨慎转换。
- 用
std::numeric_limits<short>::max()</short>和::min()做边界检查，而不是手写32767 - 加法前判断：
if (a > std::numeric_limits<short>::max() - b) { /* 溢出 */ }</short>（注意：这里减法本身也可能溢出，更稳妥用long long转换后比较） - 简单粗暴但有效：所有中间计算用
int，只在存储或传参时转short，并加断言：assert(val >= std::numeric_limits<short>::min() && val ::max());</short>
为什么不能依赖编译器自动检测溢出
因为标准没要求，而且开启溢出检测（如 UBSan）会带来运行时开销，还可能掩盖真正的问题逻辑。
立即学习“C++免费学习笔记（深入）”；
-
-fsanitize=undefined能捕获运行时有符号溢出，但仅限调试；上线必须关，否则性能跌、行为不可控 - 静态分析工具（如 clang-tidy）能发现部分常量溢出，但对变量组合无能为力
- 有些平台（如某些 DSP 或裸机环境）甚至不支持 UBSan，连调试都做不到
struct 里放 short 真的省空间吗
不一定。结构体对齐会让单个 short 实际占更多字节，比如 struct { short a; int b; } 很可能占 8 字节（a 后补 2 字节对齐），和全用 int 一样大。
- 只有连续多个
short（如数组、struct { short x, y, z; }）才大概率节省内存 - 跨平台时注意：
short至少 16 位，但某些嵌入式平台可能是 32 位，sizeof(short)不保底是 2 - 网络传输或文件存储中用
short，务必确认协议定义的是 exactly 16-bit signed integer，而非“小整数”的模糊描述
最麻烦的地方往往不在运算本身，而在你忘了它会被提升、被截断、被对齐、被平台悄悄改大小——这些细节不写在代码里，只藏在编译器手册和 ABI 文档里。
