short传参时按整型提升规则转为int，除非函数形参明确声明为short；可变参数函数需手动转换，重载易误选，跨平台需注意符号性和字节序，性能无优势。
short int 传参时自动提升为 int，函数签名要匹配
直接把 short int 变量传给形参是安全的，但编译器会按整型提升规则把它转成 int——除非你显式声明函数参数是 short 或 short int。很多人以为“传什么类型就收什么类型”，结果发现函数里 sizeof 出来是 4 而不是 2，其实是提升在起作用。
- 函数定义用
void f(short x)，调用f(my_short)：不会提升，sizeof(x)是 2 - 函数定义用
void f(int x)，调用同上：my_short被隐式转换为int，值不变但占 4 字节 - 可变参数函数（如
printf）中传short：必须手动转，printf("%hd", (short)x)，否则行为未定义
函数重载时 short 和 int 容易误选
如果你写了两个重载函数：void g(short) 和 void g(int)，传一个字面量比如 g(123)，编译器选的是 g(int)——因为整数字面量默认是 int 类型。但传变量 short s = 123; g(s); 就会精确匹配 short 版本。
- 检查重载解析：用
auto+decltype看实际类型，比如decltype(s)是short - 避免歧义：不要依赖小整数常量自动转
short，显式写g(static_cast<short>(123))</short> - 注意
char、bool也会被提升，和short同属“小整型”，行为一致
跨平台传递 short 时大小和符号性不能假设
short 在 C++ 标准里只要求 ≥16 位，实际在所有主流平台（x86/x64/ARM）确实是 16 位，但符号性（signed/unsigned）取决于声明。如果你写 short x;，它等价于 signed short；而 unsigned short 是完全不同的类型，不能隐式转给 short 参数。
- 网络或文件序列化时别直接 memcpy
short：大小虽固定，但字节序（endianness）不保证，需用htons()等处理 - 结构体里放
short要警惕内存对齐：编译器可能在前后插入 padding，sizeof不等于各成员之和 - 模板推导中
short会被当作独立类型，std::is_same_v<decltype short></decltype>才为 true
性能上 short 传参没优势，别为了“省空间”硬用
寄存器宽度是 32 或 64 位，传 short 和传 int 在调用约定下开销几乎一样。现代 CPU 对 32 位操作更友好，强行用 short 可能触发额外的截断指令（比如 movzx/movsx），反而慢一点。
立即学习“C++免费学习笔记（深入）”；
- 函数参数用
short主要是为了语义清晰（比如表示范围确定在 -32768~32767 的索引） - 局部变量用
short几乎无意义，栈空间分配按对齐单位走，未必真省字节 - 数组或大量数据才值得考虑
short：内存带宽和缓存友好性在这里起作用，单个参数不值得折腾
真正容易被忽略的是：函数参数类型决定了 ABI 兼容性。如果头文件里声明 void h(short)，但实现时悄悄改成 void h(int)，链接会失败或调用错乱——这种问题在动态库或跨模块调用时才暴露，调试起来很隐蔽。
