short位运算前必提升为int，结果为int而非short；位域中short易致对齐/截断问题；与uint16_t混用可能因符号转换导致值翻转。
short 类型做位运算前必须先提升为 int
直接对 short 变量用 &、|、^、、<code>>> 会触发整型提升（integer promotion），结果类型是 int，不是 short。这不是 bug，是 C++ 标准行为——所有小于 int 的整型在参与算术或位运算前都会被转成 int。
常见错误现象：short a = 0x8000; short b = a 看似左移一位，实际执行的是 <code>(int)a ，结果是 <code>0xffff0000（如果 int 是 32 位），再截断赋值给 b 就变成 0x0000 或负数溢出，和预期不符。
- 使用场景：需要保持高位截断语义时（比如模拟硬件寄存器低 16 位操作）
- 必须显式强制转换回
short：如(short)(a ，否则高位信息丢失不可控 - 注意符号扩展：若
a是负的short（如0xfffe），提升为int后仍是负数（0xfffffffe），左移可能引发未定义行为（带符号左移负数）
右移 short 时符号位处理很关键
short 是有符号类型，>> 是算术右移，高位补符号位。但提升后操作的是 int，所以实际补的是 int 的符号位，不是原始 short 的。
示例：short x = -1; // 二进制 0xffff（16 位） → 提升为 int 后是 0xffffffff → x >> 1 得 0xffffffff（仍是 -1），而非 0x7fff。
立即学习“C++免费学习笔记（深入）”；
- 想实现逻辑右移（高位补 0），得先转成无符号类型：
(unsigned short)x >> 1 - 若原值来自外部数据（如网络字节流、内存映射寄存器），建议一开始就用
uint16_t，避免符号歧义 - 编译器不会警告这种“看似合理实则语义漂移”的操作
位域中用 short 容易踩对齐和截断坑
在结构体位域里声明 short 成员（如 short flag : 4;）是合法的，但标准不保证它占多少字节，也不规定是否跨 short 边界——实际由编译器决定，且通常按整个 int 或 short 对齐。
常见错误现象：两个 short 位域加起来 16 位，本以为刚好塞进一个 short，结果编译器生成了 4 字节空间，中间还有填充；或者不同平台下布局不一致，导致序列化失败。
- 位域宽度不能超过其基础类型的位宽（
short最多 16 位，flag : 17是非法的） - 不要假设位域在内存中连续紧凑排列；调试时用
sizeof和offsetof实测 - 跨平台项目慎用
short位域，优先考虑uint16_t : N并配合static_assert(sizeof(uint16_t) == 2)
与 uint16_t 混用时隐式转换可能丢数据
short 和 uint16_t 在多数平台都占 2 字节，但语义完全不同：short 有符号，uint16_t 无符号。混用时 C++ 允许隐式转换，但值可能意外翻转。
例如：short s = -1; uint16_t u = s; → u 变成 65535（补码解释），而不是你期望的截断或报错。
- 编译器通常不报错，但开启
-Wsign-conversion（GCC/Clang）能捕获这类隐式转换 - 函数参数传递时尤其危险：
void foo(uint16_t x)接收short会静默转换，调用方完全感知不到 - 位运算中混用更隐蔽：如
s & 0xff结果是int，而u & 0xff也是int，但初始值语义已不同
真正麻烦的地方不在语法能不能写，而在调试时发现值“莫名其妙变了”，却要倒推整条表达式里的每次提升和转换。位操作本身不复杂，但 short 的符号性 + 提升规则 + 平台字长，三者叠在一起，很容易漏掉一次强制转换或一个警告标志。
