short 变量命名要不要加 _short 或 s_ 前缀
不用。C++ 里 short 是语言内置类型，不是业务概念，加类型前缀反而干扰语义。命名应反映「它存的是什么」，而不是「它占几个字节」。
比如你存一个传感器采样周期（单位毫秒），范围确定在 -32768~32767 内，用 short 纯属节省内存——那变量就该叫 sample_period_ms，而不是 s_sample_period 或 sample_period_short。
- 类型前缀在 C 风格或老嵌入式代码里偶见，但现代 C++ 更强调意图清晰，IDE 和静态分析工具也能立刻告诉你变量类型
- 如果团队真有类型编码规范（如
i16_），必须全项目统一，且只在明确需要跨平台类型对齐时才启用（比如协议序列化），日常逻辑层不推荐 -
short在不同平台实际大小可能不同（虽然几乎总是 16 位），靠名字暗示类型反而制造虚假确定性
什么时候该用 short 而不是 int
只在两个条件同时满足时才考虑：short 的取值范围确实够用，且内存布局敏感。
典型场景是大型数组、结构体成员、网络/文件协议字段。比如一个含 10 万个点的二维坐标数组，用 short 存像素坐标（-32768~32767）能省一半内存；但若只是临时计算中间值，一律用 int ——现代 CPU 对 int 运算更友好，隐式提升还可能引入意外截断。
立即学习“C++免费学习笔记（深入）”；
- 别为单个变量省 2 字节：编译器会对齐填充，
short成员后面跟double，很可能没省下空间 - 函数参数和返回值避免用
short：调用时会整型提升为int，容易和重载、模板推导冲突 - 用
int16_t替代裸short更安全，尤其涉及跨平台或序列化时——它明确保证 16 位有符号
short 初始化和字面量的坑
直接写数字字面量（如 42）默认是 int，赋给 short 会触发隐式转换，编译器可能警告（-Wshorten-64-to-32 类似选项），运行时也可能溢出。
常见错误现象：short x = 100000; 编译不报错但值是截断后的负数（如 -31072），调试时很难发现。
- 显式字面量后缀不存在（C++ 没有
42s这种语法），只能靠强制转换或用户定义字面量（不实用） - 初始化尽量用已知在范围内的常量：比如
constexpr short MAX_RETRY = 5;，而非运行时计算结果 - 读配置或输入时，先读到
int，再检查范围并显式转换：if (val >= std::numeric_limits<short>::min() && val ::max()) { x = static_cast<short>(val); }</short></short>
结构体里 short 成员的对齐和 padding 影响
结构体大小不等于成员大小之和，short 的自然对齐是 2 字节，但编译器会按最大成员对齐（通常是 8 字节）。放错顺序可能让结构体凭空变大。
比如：struct { char a; short b; char c; }; 实际大小通常是 6 字节（a+pad+b+c+pad），而不是 4 字节。把 short 放前面或按大小降序排列能减少 padding。
- 用
alignas(2)强制对齐不会减小结构体，反而可能破坏默认对齐导致性能下降 - 调试时用
offsetof或sizeof验证布局，别凭感觉 - 如果结构体要写入文件或发网络，必须用
#pragma pack(1)或[[gnu::packed]]，但注意这会让访问变慢，且某些平台不支持未对齐访问
真正难的不是选 short 还是 int，而是判断「这个变量的生命周期、作用域、是否参与计算、是否进缓存行」——这些决定了类型选择的权重。类型名只是表象，数据流动路径才是关键。
