int 转 short 会截断，不是“转换”而是“位截取”
直接 static_cast<short>(x)</short> 或 (short)x 不是安全的类型转换，而是把 int 的低 16 位原样拷贝给 short。如果原值超出 short 范围（通常是 −32768 到 32767），结果是实现定义的——多数编译器做模运算或直接截断，但不保证符号正确。
- 常见错误现象：
int x = 40000;→short y = static_cast<short>(x);</short>得到-25536（补码截断），而非报错或饱和 - 使用场景：仅当你能 100% 确保输入在
short取值范围内，比如协议字段解析时已知数据被约束 - 别依赖编译器警告：GCC/Clang 默认不报
int→short截断警告，需加-Wconversion才提示
需要安全截断？自己写检查逻辑
标准库没提供带范围检查的 int→short 转换函数，得手动判断。靠 std::numeric_limits 比硬编码数字更可读、跨平台。
- 推荐写法：
if (x < std::numeric_limits<short>::min() || x > std::numeric_limits<short>::max()) { // 处理溢出：抛异常 / 返回默认值 / 记 log } short y = static_cast<short>(x); - 性能影响：一次比较 + 一次转换，现代 CPU 分支预测好时几乎无开销；别为了省这两次比较去用
reinterpret_cast自欺欺人 - 注意
short有符号性：unsigned short的上限是 65535，下限是 0，检查逻辑要同步改
用 std::narrow？C++20 才有，且行为不等于“安全转换”
std::narrow（定义在 <span></span>）只对 char/signed char/unsigned char 重载，不支持 int→short。想用它必须先转成 char 类型，完全不适用。
- 错误用法：
std::narrow<short>(x)</short>→ 编译失败，没有这个模板特化 - 替代方案：C++20 也没补上整型窄化工具，还是得手写范围检查
- 兼容性坑：若项目要支持 C++17 或更早，连
std::narrow都不可用，别引入无谓依赖
struct 成员或 memcpy 强制解释？危险，除非你控制内存布局
有人用 memcpy(&s, &i, sizeof(short)) 或 union 解释同一块内存，这属于未定义行为（UB）或至少是实现定义——尤其当 int 和 short 对齐要求不同、或系统大小端敏感时。
立即学习“C++免费学习笔记（深入）”；
- 典型翻车点：在 ARM64 或某些嵌入式平台，
int是 4 字节对齐，short是 2 字节，memcpy从int*地址取前 2 字节可能触发对齐异常 - union 方式（如
union { int i; short s; } u;）违反严格别名规则，优化开启（-O2）后编译器可能生成错误代码 - 唯一能勉强接受的场景：裸机驱动或通信协议解析，且明确知道源数据就是按小端/大端排列的 2 字节字段，此时应直接用
uint8_t[2]+ 手动拼接
