应使用 std::numeric_limits 查整数范围，因其编译期确定、泛型安全；加减乘运算前须手动检查防溢出，避免未定义行为；优先用 std::optional 或状态结构体表示失败，而非特殊值。
用 std::numeric_limits 查范围，别靠记忆
整数溢出不是运行时自动报错，而是未定义行为——程序可能看似正常，但结果错得离谱。C++ 不做默认检查，所以得自己确认变量能装下什么。std::numeric_limits 是唯一靠谱的查法，比查文档、背常量或写 INT_MAX 更安全、更泛型。
-
std::numeric_limits<int>::max()</int>返回当前平台int的最大值（通常是 2147483647），不是固定值 - 对
unsigned int用std::numeric_limits<unsigned int>::max()</unsigned>，别混用有符号版本 - 模板函数里要检查类型 T 的边界？直接写
std::numeric_limits<t>::min()</t>和std::numeric_limits<t>::max()</t>，编译期确定 - 注意：
char默认可能是 signed 或 unsigned，查之前先明确是signed char还是unsigned char
加减乘前手动检查，别等溢出了再补救
运行时检测必须在运算发生前做，否则 a + b 已经溢出，再查 a + b > std::numeric_limits<int>::max()</int> 就晚了——表达式本身已触发未定义行为。
- 加法检查：
a > std::numeric_limits<int>::max() - b</int>（仅限正数）；更通用写法是用std::add_overflow（C++23）或第三方库如absl::checked_add - 乘法尤其危险：
a * b很容易悄无声息地翻转，检查要写成b != 0 && a > std::numeric_limits<int>::max() / b</int>，还得分别处理负数和零 - 不要用异常兜底：溢出不是异常场景，抛异常开销大，且掩盖了设计缺陷
- 如果逻辑允许，优先用更大类型临时计算，比如
long long存int运算结果，再判断是否回得去
启用编译器溢出检测（-fsanitize=undefined）只用于调试
UBSan 能在运行时报出 signed integer overflow 这类错误，但它不是生产环境解决方案——它会拖慢程序 2–5 倍，且不覆盖所有溢出路径（比如某些位运算、指针算术）。
- 开发阶段加
-fsanitize=undefined -fno-omit-frame-pointer，配合UBSAN_OPTIONS=abort_on_error=1让崩溃更明显 - 它不捕获
unsigned溢出（C++ 标准规定这是定义良好的“回绕”），所以不能依赖它发现所有问题 - CI 流水线里跑 UBSan 是好习惯，但上线前必须把报出的问题转为静态检查或显式防护，而不是留着 sanitizer
- Clang 和 GCC 都支持，但 MSVC 不支持；跨平台项目要注意构建配置隔离
用 std::optional<T> 或返回状态码代替“用特殊值表示失败”
有人喜欢用 -1 或 INT_MIN 表示计算失败，但这和业务语义冲突，也增加调用方误判风险。
立即学习“C++免费学习笔记（深入）”；
- 函数本意是“算一个安全的 int”，那就该返回
std::optional<int></int>，成功时有值，失败时为空 - 避免重载含义：比如
int parse_number(const std::string&)返回-1可能是解析失败，也可能是真的输入了"-1" - 如果性能敏感、不能用
std::optional（比如嵌入式），至少用结构体封装：struct Result { bool ok; int value; }; - 别用异常替代——整数范围检查是预期中的边界判断，不是异常条件
真正麻烦的从来不是“怎么写检查”，而是“哪些地方该检查”。算子、IO 解析、协议字段解包、容器索引计算……这些位置最容易漏。只要涉及用户输入、外部数据或循环累加，就该默认加一层范围防护。
