INT_MAX 定义在 <climits> 中，是 C++ 标准头文件提供的整型常量宏；<limits> 提供 std::numeric_limits<int>::max()，<cstdint> 提供 INT32_MAX 等固定宽度类型常量。
INT_MAX 在哪个头文件里定义
在 C++ 里，INT_MAX 定义在 <climits> 中（C 风格头文件），不是 <limits> 或 <cstdint>。虽然 <limits> 提供了更泛化的 std::numeric_limits<int>::max()，但直接写 INT_MAX 就得包含 <climits>。
常见错误现象：error: 'INT_MAX' was not declared in this scope——基本就是忘了 #include <climits>，或者误用了 <limits.h>（C 头文件，在 C++ 中可用但不推荐）。
- 用 C++ 项目时，优先写
#include <climits>，不是<limits.h> -
<climits>是标准 C++ 头文件，宏定义如INT_MAX、CHAR_MIN全在里面 -
<limits>不提供INT_MAX这种宏，只提供模板类std::numeric_limits
INT_MAX 和 std::numeric_limits<int>::max() 的区别
两者都返回 int 类型能表示的最大值，但来源、类型和使用场景不同。
INT_MAX 是一个整型常量宏（通常是 2147483647），类型是 int；而 std::numeric_limits<int>::max() 是 constexpr 函数调用，返回类型严格匹配 int，且支持所有算术类型（比如 long long、unsigned short）。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 需要快速写死最大值、兼容旧代码或做宏判断（如
#if INT_MAX > 32767），用INT_MAX - 写泛型代码、模板函数，或需要编译期常量表达式（constexpr context），优先用
std::numeric_limits<int>::max() -
std::numeric_limits<int>::max()在<limits>中，必须显式#include <limits>
INT_MAX 在不同平台/编译器下是否可靠
可靠，但前提是「int 是 32 位有符号整数」这个假设成立——而这正是绝大多数现代平台（x86-64、ARM64、主流编译器默认）的实际情况。
不过 C++ 标准只要求 int 至少 16 位，INT_MAX 的具体值由实现定义。所以不能假设它一定是 2147483647，尤其在嵌入式或非主流平台上。
- 如果逻辑强依赖
int是 32 位（比如协议解析、内存布局计算），建议改用固定宽度类型：用int32_t+INT32_MAX（来自<cstdint>） -
INT32_MAX保证是 32 位，且定义在<cstdint>，比INT_MAX更明确 - 检查实际值？可以加个静态断言：
static_assert(INT_MAX == 2147483647, "int is not 32-bit");
为什么有时候用 INT_MAX 会触发警告或溢出
最常见原因是把它当作「无穷大」参与计算，却忽略了它本身是可被超越的边界值。比如 INT_MAX + 1 是未定义行为（signed integer overflow）；又或者在比较中写 if (x ——这永远为真，毫无意义。
- 别对
INT_MAX做算术运算（+1、*2 等），除非你确认不会溢出且有 fallback - 用作哨兵值（sentinel）时，确保业务逻辑不会意外生成等于
INT_MAX的合法数据 - 算法中需要“无穷大”语义？考虑用
std::optional<int>或单独的布尔标志，而不是硬塞INT_MAX - 调试时发现值突然变成负数？大概率是
INT_MAX + 1导致的回绕，不是INT_MAX本身的问题
真正容易被忽略的是：宏定义的 INT_MAX 没有类型安全，不参与 ADL，也不能被模板推导。一旦混用 int 和 long，或跨平台移植，靠它写的边界逻辑就可能悄无声息地失效。
