应使用 std::numeric_limits::min() 获取 short 最小值，它类型安全、constexpr、可读性强；SHRT_MIN 仅适用于纯 C 兼容场景。
怎么拿到 short 的最小值？用 std::numeric_limits，别碰 SHRT_MIN 除非你真在写 C 兼容代码
标准 C++ 推荐方式是 std::numeric_limits<short>::min()</short>，它在 <limits></limits> 头文件里。这比宏 SHRT_MIN 更类型安全、更可读，也避免了宏展开带来的意外（比如被其他头文件污染或和自定义宏冲突）。SHRT_MIN 来自 C 标准库 <climits></climits>，虽然合法，但 C++ 中它只是“兼容性存在”，不参与模板推导、不能用于 constexpr if 分支判断。
- 必须
#include <limits></limits>才能用std::numeric_limits -
std::numeric_limits<short>::min()</short>是constexpr，可直接用在数组大小、模板参数等编译期上下文中 - 如果项目要同时支持 C 和 C++，且已大量使用
SHRT_MIN，那保持也行；但新代码优先选std::numeric_limits
short 真的是 16 位吗？别假设，查 sizeof 和 std::numeric_limits::digits
C++ 标准只要求 short 至少 16 位，不保证恰好 16 位。实际大小取决于平台和编译器：x86-64 Linux/macOS 下通常是 16 位，但某些嵌入式平台或老编译器可能给 32 位。靠经验猜会出问题，尤其做序列化、内存映射或跨平台二进制协议时。
- 用
sizeof(short)看字节数，再乘 8 得理论最大位宽 - 用
std::numeric_limits<short>::digits</short>看实际能表示的二进制位数（不含符号位） -
std::numeric_limits<short>::is_signed</short>为true，说明是补码有符号类型，最小值就是-2^(digits)
为什么 std::numeric_limits<short>::min()</short> 返回负数，但 std::numeric_limits<unsigned short>::min()</unsigned> 是 0？
这是类型语义决定的：short 是有符号整型，补码表示下最小值是负数；unsigned short 是无符号，下界自然为 0。混淆两者会导致静默错误——比如把 short 值赋给 unsigned short 变量，负数会绕回极大正数（如 -1 → 65535），而编译器通常不警告。
- 函数签名、模板参数、容器元素类型写错符号性，比数值越界更难调试
- 用
auto推导时，注意源表达式是否带符号（例如static_cast<short>(-1)</short>是有符号，1u是无符号） - 打印调试时，用
%hd（short）和%hu（unsigned short）区分，否则printf行为未定义
宏 SHRT_MIN 在哪些场景下真得用？
极少。只在两种情况：一是写纯 C 接口头文件，需要被 C 代码 #include；二是和旧版 C 库（如 POSIX API）交互，其文档明确要求传 SHRT_MIN。除此之外，它没优势——不能 SFINAE，不能偏特化，不能随类型自动适配。
立即学习“C++免费学习笔记（深入）”；
- 混用
SHRT_MIN和std::numeric_limits容易引发比较陷阱：比如SHRT_MIN == std::numeric_limits<short>::min()</short>在多数平台成立，但不是语言保证 - 预处理器宏无法被 IDE 正确跳转或重命名，重构困难
- 如果用了
SHRT_MIN，记得确认<climits></climits>已包含，且没被其他头文件意外#undef
short 不保底 16 位、没检查符号性、或者在模板元编程里误把宏当常量表达式用。 
