C++里的“+ - *”不是数学课作业，是和内存讨价还价的日常

刚写完一行 int a = b + c;，你有没有想过：这“加号”到底在替你干啥？它没在黑板上列竖式，也没调用计算器——它是在跟内存地址、数据类型、甚至CPU指令集悄悄谈判。C++的算术操作符（+, -, *）表面平平无奇，实则每一步都在做隐式决策：该用什么指令？要不要截断？类型怎么升格？溢出谁来兜底？

很多人学完“整型相加得整型”，就默认所有+都安全。可当你把unsigned char x = 255; 和 int y = 1; 相加，结果不是0（像模256那样），而是256——因为x先被整型提升为 int，再参与运算。这个细节不看汇编、不测边界值，光靠“数学直觉”会踩坑。

减法 - 更容易暴露认知偏差。比如 size_t i = 0; i = i - 1; ——这不是-1，而是18446744073709551615（64位下）。因为size_t是无符号类型，减法本质是模运算。编译器不会报错，但你的循环可能跑飞成永动机。这不是bug，是语言设计的选择：C++把“类型语义”放在“数学直觉”前面，你要主动对齐，而不是指望它迁就你。

乘法 * 是三者中最危险的。两个int相乘，结果可能溢出，而C++标准明确不保证溢出检测——它直接静默回绕（wrap-around）。INT_MAX * 2 不抛异常，不告警，只给你一个负数。Clang/GCC加 -fsanitize=undefined 能抓到，但上线代码若没开，就是定时雷。更隐蔽的是：short a = 30000, b = 30000; auto c = a * b;——你以为c是short？错。*乘法结果类型由操作数提升后决定，这里实际是int，值为9亿（不溢出），但如果你强制`static_cast(a b)`，才真正截断。**

这些操作符从不孤立工作。它们嵌在表达式里，受结合律、求值顺序、临时对象生命周期牵制。比如 a = b + c * d;，乘法优先级高是常识，但若c和d是自定义类，operator*返回一个临时对象，而operator+又接受右值引用重载——这时b + (c * d)的中间结果生命周期，可能影响性能甚至正确性。算术符背后是类型系统与内存模型的合谋，不是语法糖，是接口契约。

怎么写得更稳？三条落地建议：

• 显式控制类型宽度：用int32_t代替int，用static_cast<int64_t>(a) * b避免意外截断；
• 关键计算前校验范围：乘法前用 if (a > 0 && b > 0 && a > INT_MAX / b) 判断是否溢出（注意除零）；
• 让编译器帮你盯梢：开发期启用-ftrapv（捕获有符号溢出）或-fsanitize=integer，比靠人肉review靠谱得多。

有人觉得“我只做业务逻辑，不用碰底层”。但当你调试一个偶发的负数ID生成、一个莫名其妙的数组越界、或一个时快时慢的数值聚合——追到最后，常是某个+或*在类型转换中悄悄改写了语义。C++的算术操作符不是数学符号的复刻，它是你和硬件之间最短也最易滑脱的那根绳子。握紧它，不靠记忆口诀，而靠每次写+时心里默念一句：“这次，我清楚它的类型、宽度、和退路。”

下次看到a * b，别只读作“a乘b”。读作：“a与b按规则提升，交由ALU执行IMUL，结果存入目标类型，溢出无人喊停——除非你提前设好哨兵。”