unsigned short int 的取值范围至少为 0 到 65535，但位宽不固定；应使用 std::numeric_limits::max() 获取上限，需用 uint16_t 保证精确 16 位宽度。
unsigned short int 在标准 C++ 中的取值范围是 0 到 65535（即 2^16 - 1），前提是它占 16 位 —— 这在绝大多数现代平台（x86、x64、ARM64）上成立，但不是 C++ 标准强制保证的。
为什么不能直接写死 0–65535？
C++ 标准只要求 unsigned short int 至少能表示 0 到 65535，实际位宽由编译器和平台决定。虽然现实中几乎全是 16 位，但标准允许更大（比如 20 位或 32 位），只要满足最小范围要求即可。
- 依赖
sizeof(unsigned short) == 2是常见错误假设，sizeof返回的是字节数，不是位数；而CHAR_BIT可能不是 8（极少见，但标准允许） - 真正可移植的下限/上限应来自
<limits></limits>：用std::numeric_limits<unsigned short>::min()</unsigned>和std::numeric_limits<unsigned short>::max()</unsigned> - 硬编码
65535在嵌入式或非主流 ABI（如某些 DSP 平台）上可能溢出或截断
什么时候该用 uint16_t 而不是 unsigned short？
当你需要确定无歧义的 16 位宽度时，必须用 uint16_t（来自 <cstdint></cstdint>）。它只在平台支持 16 位精确整型时才定义，否则根本不可用 —— 这反而是好事，能提前暴露移植问题。
-
unsigned short是“至少 16 位”，uint16_t是“恰好 16 位” - 网络协议、二进制文件格式、硬件寄存器映射等场景，位宽错一位就全乱
- 注意：
uint16_t不是关键字，是 typedef；若编译失败，说明目标平台不提供原生 16 位类型（此时得换策略，比如用uint_least16_t）
unsigned short 在函数参数和 ABI 中的隐含风险
它在跨语言调用（比如 C++ 导出给 Rust 或 Python ctypes）或结构体布局中容易引发对齐和大小不一致问题。不同编译器对 unsigned short 的默认对齐可能不同，尤其在打包结构体时。
立即学习“C++免费学习笔记（深入）”；
- 结构体里混用
unsigned short和char时，sizeof可能因填充而大于预期 - Windows MSVC 和 GCC 对
#pragma pack处理略有差异，unsigned short的偏移可能跑偏 - 导出为 C 接口时，建议显式用
uint16_t，避免 C 头文件里unsigned short被其他语言解释成不同宽度
真正麻烦的从来不是范围本身，而是你以为它“肯定就是 16 位”那一刻 —— 尤其当代码要跑在新芯片、旧工控设备或者别人封装好的 SDK 里时。
