short赋值超范围时编译器不报错但结果错误，因其为有符号16位整型（-32768~32767），超限字面量如33000会静默绕回为-32536；建议开启-woverflow警告并校验范围后再static_cast。
short 赋值时超出范围，编译器不报错但结果不对
因为 short 是有符号 16 位整型，取值范围是 -32768 到 32767。直接赋一个超限字面量（比如 33000），C++ 标准允许实现做模运算截断，结果是未定义行为（UB）或实现定义行为——常见表现是“静默绕回”，比如 33000 变成 -32536。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 开启编译器警告：GCC/Clang 加
-Woverflow，能捕获字面量初始化越界；MSVC 用/Wall或至少/W4 - 避免裸写大数字：用
static_cast<short>(x)</short>显式转换前先校验x >= -32768 && x - 别依赖
sizeof(short) == 2：POSIX 和 Windows 下通常是，但 C++ 标准只要求 ≥ 16 位，嵌入式平台可能不同
从 int 读取数据到 short 时发生静默截断
典型场景是网络协议解析、文件二进制读取、或跨平台结构体 memcpy。比如把 int 类型的 value = 40000 直接存进 short 字段，不会触发异常，但高位被丢弃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::numeric_limits<short>::min()</short>和max()做运行时检查，而不是硬编码-32768/32767 - 考虑用
std::span<const std::byte></const>+std::bit_cast（C++20）替代 raw memcpy，减少类型擦除风险 - 如果必须压缩存储，优先用无符号类型（如
uint16_t）并明确文档其语义，避免符号扩展混淆
函数参数传 short 导致隐式提升和比较陷阱
C++ 会把 short 实参自动提升为 int（整型提升规则），所以 void f(short x) 和 void f(int x) 是不同重载，但调用 f(123) 会绑定到 int 版本——除非你显式写 f(static_cast<short>(123))</short>。
更隐蔽的问题是：两个 short 变量比较时，实际比的是提升后的 int，但如果其中一个来自越界赋值（比如绕回成负数），逻辑就错乱了。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 函数接口尽量用
int16_t替代short，语义清晰且大小确定 - 避免重载
short和int版本，容易引发调用歧义 - 日志或调试时打印值，用
static_cast<int>(x)</int>强制转成整数再输出，防止终端误判符号位
序列化/反序列化中 short 字段被错误解释
比如用 memcpy(&s, buf, sizeof(s)) 把字节流拷进 short s，但 buf 里存的是大端序数据，而本地是小端，结果就是错的——这不是溢出，但常被误认为“值异常”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永远明确字节序：网络字节序用
ntohs()/htons()转换，别直接 memcpy - 结构体加
[[gnu::packed]]或#pragma pack(1)时，确认short对齐没被破坏，否则 memcpy 可能读越界 - 单元测试里构造边界值（
-32768、32767、32768）验证序列化 round-trip 正确性
最麻烦的不是溢出本身，而是它经常藏在类型转换链的中间层，比如 int → short → uint16_t → char[2]，每一步都可能丢信息，又没有编译器提示。盯住每个转换点，手动加断言比指望静态分析更可靠。
