int 和 long 的大小因平台而异：windows x64 下均为32位，linux x64 下 int 为32位、long 为64位；应优先使用 int32_t/int64_t 等固定宽度类型，避免跨平台兼容性问题。
int 和 long 在不同平台上的实际大小不一致
它们没有固定字节数，c++ 标准只规定了最小范围：int 至少 16 位，long 至少 32 位。这意味着在 Windows x64（MSVC）下 int 和 long 都是 32 位；但在 Linux x64（GCC）下 int 是 32 位、long 是 64 位——同一份代码编译结果可能不同。
常见错误现象：sizeof(long) == sizeof(int) 在 Windows 上为真，在 Linux 上为假；跨平台传递二进制结构体时字段错位。
- 别依赖
sizeof(long)等于 4 或 8，用std::numeric_limits<long>::digits</long>查实际位数 - 需要确定宽度时，优先用
int32_t、int64_t（需#include <cstdint></cstdint>） - 接口参数若涉及大小敏感场景（如系统调用、网络协议），明确写
int32_t而非long
long long 是唯一被标准强制要求 ≥64 位的整型
long long 自 C++11 起被要求至少 64 位，且几乎所有现代编译器都实现为 exactly 64 位。它比 long 更可预测，尤其在需要大整数但又不想引入 int64_t 的轻量场景中。
使用场景：时间戳计算（如 nanoseconds since epoch）、哈希值中间运算、避免 32 位乘法溢出。
立即学习“C++免费学习笔记（深入）”；
-
long long字面量必须带LL后缀，比如1000000000000LL，否则可能被当int截断 - 和
long混用时注意隐式转换：long x = 1L; long long y = x * 1000000LL;中乘法在long long上进行，但若写成x * 1000000，则先按long算再提升，可能溢出 - Windows API 中几乎不用
long long，而大量用LONGLONG（等价于long long），但头文件里定义方式不同，直接混用可能触发类型不匹配警告
printf/scanf 中的格式符必须和实际类型严格匹配
用错格式符是运行时未定义行为，轻则输出乱码，重则崩溃。比如在 64 位 Linux 下用 %d 打印 long（实际 64 位），会只读前 4 字节，结果不可控。
常见错误现象：printf("%d", my_long_var) 在 GCC 编译时可能报警告，但 MSVC 默认不报；scanf("%ld", &my_int_var) 会导致栈写越界。
-
int→%d，long→%ld，long long→%lld - Windows 下
long long的 scanf 格式符有时要写%I64d（尤其旧 MSVC），但 C++11 后推荐统一用%lld并确保编译器支持 - 更安全的做法是用
std::cout或fmt::format，避开 C 风格格式符的类型陷阱
性能差异几乎可以忽略，但 ABI 兼容性影响真实项目
在现代 CPU 上，32 位和 64 位整数运算指令周期数基本一致，缓存占用差异也微乎其微。真正卡住人的，是 ABI（应用二进制接口）层面的约束：DLL 导出函数签名、结构体内存布局、跨语言绑定（如 Python ctypes）都依赖类型的精确大小和对齐。
例如：一个导出函数返回 long，在 Windows 上是 32 位，在 Linux 上是 64 位，Python 用 ctypes.c_long 加载时会因长度不匹配读错数据。
- 对外暴露的接口类型，一律用固定宽度类型（
int32_t/uint64_t）或明确注释平台假设 - 结构体中混用
int和long时，用static_assert(sizeof(MyStruct) == N, "...")锁死大小 - 不要为了“省点内存”在 64 位程序里坚持用
int存指针差值——该用ptrdiff_t就用，它才是语义正确的类型
最麻烦的不是大小本身，而是有人在头文件里写了 typedef long time_t，然后你改了编译器或平台，整个时间处理逻辑就悄悄错位了。