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 及之后标准强制保证的下限——你写 l

为什么不能只靠 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 位，但名字本身不体现位宽。

• 头文件必须加：#include
• 声明变量：int64_t counter = 0;，比 long long counter 更直白表达意图
• 注意：int64_t 不一定存在（极少数平台无 64 位整型），此时 std::optional 或退回到 long long 是合理 fallback

真正容易被忽略的不是“它能存多大”，而是“它溢出时不说话”。哪怕你记住了 9223372036854775807，只要没在关键路径做溢出防护，一个 + 就可能让结果彻底错乱且难以复现。