short加法易悄无声息出错，因整型提升使运算实际在int上进行，溢出仅发生在赋值回short时，属未定义行为；安全做法是先提升至int计算并检查范围，再显式转换。
short 加法为什么容易悄无声息地出错
因为 short 是有符号整型，通常占 2 字节（-32768 到 32767），但 C++ 在算术运算中会自动执行「整型提升」：只要参与运算的类型窄于 int，编译器就会先把它们转成 int 再算。表面看是 short + short，实际执行的是 int + int，结果也是 int —— 所以溢出不会在加法那一刻触发，而是在你把结果存回 short 变量时才发生截断。
- 常见错误现象：
short a = 32767; short b = 1; short c = a + b;，你以为c是 -32768？其实它可能是 32768（未定义行为），或被编译器优化掉判断逻辑 - 真正危险的不是加法本身，而是赋值回
short的那一步：c的类型是int，强制转成short属于「有符号整数溢出」，C++ 标准明确定义为未定义行为（UB） - 不同编译器表现不一：GCC 可能保留低 16 位（看似“绕回”），Clang 在 -fsanitize=undefined 下直接报错，Release 模式下甚至可能删掉整个分支
怎么安全地做 short 加法
别依赖隐式转换，显式控制边界和类型。核心原则：加之前升到足够宽的类型，加完再检查，最后只在确认安全时才缩回 short。
- 用
int或long中间变量承接结果，避免直接赋给short：int tmp = static_cast<int>(a) + static_cast<int>(b);</int></int> - 检查是否仍在
short范围内再赋值：if (tmp >= std::numeric_limits<short>::min() && tmp ::max()) { c = static_cast<short>(tmp); }</short></short> - 如果性能敏感且确定输入可控（比如传感器采样值固定在 ±2000 内），可跳过检查，但必须在注释里写死范围依据，不能靠“应该不会超”
std::short_add 不存在，别找标准库捷径
C++ 标准库没有提供带溢出检查的 short 专用算术函数。有人误以为 std::add 或 Boost 的某个头文件能解决，其实没有。
-
std::plus<short></short>是函数对象，不做任何溢出检查，只是包装了+运算符 -
std::midpoint、std::clamp等 C++20 新工具也都不处理加法溢出 - 第三方库如
absl::int16_t或SafeInt可用，但引入依赖前先问自己：是不是真需要运行时检查？还是编译期断言就够了？
编译器警告和 sanitizer 是唯一靠谱的帮手
靠人眼盯代码防 short 溢出基本无效。必须靠工具链暴露问题。
立即学习“C++免费学习笔记（深入）”；
- 启用
-Woverflow（GCC/Clang）能捕获部分常量折叠溢出，但对运行时值无效 - 务必加
-fsanitize=signed-integer-overflow：一旦发生有符号溢出，程序立刻中断并打印调用栈 - 注意：UBSan 会拖慢执行速度，适合测试阶段；CI 流程里应强制开启，而不是仅本地跑一下
- 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 能发现部分潜在路径，但覆盖率不如 UBSan 实际
最易被忽略的一点：结构体里两个 short 成员相加，看起来“都是小数”，但它们的符号位和范围限制完全独立，不能凭经验估算——哪怕两个值都小于 1000，加起来也可能溢出，只要其中一个为负且绝对值大。溢出检查必须按实际数值范围做，不能省。
