long long 最大值为9223372036854775807（2⁶³−1），C++11起标准强制保证至少64位，实际主流平台均为64位；溢出为未定义行为，需用std::numeric_limits或int64_t等防护。
long long 最大能存多少？直接看标准值
有符号 long long 在所有主流平台（Windows/Linux/macOS，64 位或 32 位编译器）上都是 64 位，其最大值固定为 9223372036854775807（即 2⁶³−1），最小值是 -9223372036854775808（即 −2⁶³）。这不是“大概”，而是 C++11 及之后标准强制保证的下限——你写 long long 就能放心按这个范围用。
为什么不能只靠 sizeof(long) 推 long long？
long 的大小平台相关：Windows 上是 32 位（和 int 一样），Linux/macOS 64 位系统上却是 64 位。但 long long 没这问题——它从 C++11 起就明确定义为「至少 64 位」，实际实现全为 64 位。所以：
- 需要跨平台稳定大整数 → 选
long long，别碰long - 想确认当前环境真实范围 → 用
std::numeric_limits，别硬背数字::max() - 写常量字面量时记得加后缀：
9223372036854775807LL，否则可能被当int或long导致编译错误
溢出不是报错，而是静默翻转——这是最危险的坑
C++ 对有符号整数溢出的行为是「未定义行为（UB）」，编译器可以生成任意结果（常见表现是绕回，比如 LLONG_MAX + 1 变成 LLONG_MIN），但不保证、也不提示。例如：
long long x = 9223372036854775807; x++; // 此刻 x 值不可预测；在多数编译器+优化下会变成 -9223372036854775808，但别依赖它
- 算法题/计数器/时间戳计算中，务必在运算前检查是否将溢出，尤其做加、乘、移位
- 用
std::add_overflow（C++23）或手动比较（如a > LLONG_MAX - b判断a + b是否溢出） - 调试时开启 UBSan（Undefined Behavior Sanitizer）：编译加
-fsanitize=undefined，它能在运行时报出溢出点
比 long long 更稳的选择：固定宽度类型
如果逻辑上明确需要「恰好 64 位有符号整数」，推荐用 int64_t（来自 long long 在绝大多数场景等价，但语义更清晰、可移植性更强——比如嵌入式平台或非主流 ABI 下，int64_t 是 typedef 到确切类型，而 long long 虽然也够 64 位，但名字本身不体现位宽。
立即学习“C++免费学习笔记（深入）”；
- 头文件必须加：
#include - 声明变量：
int64_t counter = 0;，比long long counter更直白表达意图 - 注意：
int64_t不一定存在（极少数平台无 64 位整型），此时std::optional或退回到long long是合理 fallback
真正容易被忽略的不是“它能存多大”，而是“它溢出时不说话”。哪怕你记住了 9223372036854775807，只要没在关键路径做溢出防护，一个 + 就可能让结果彻底错乱且难以复现。
