整数溢出，整数说白了就是溢出装不下了。C语言里一个unsigned int，处理32位，整数最大值4294967295。溢出你非要往上加1，处理它不会报错，整数不会崩溃，溢出直接翻回0。处理就这么干脆，整数连个招呼都不打。溢出

我见过最典型的处理例子，某年某电商平台的整数优惠券系统。一个int存用户领券总数，溢出活动太火爆，处理某用户领了21亿多张——别笑，真事。然后他账户里的券数量变成负数了，系统判定他欠平台券，直接封号。用户投诉到工信部，平台公关焦头烂额。程序员改了一行代码，把int换成long long，问题解决。就这么简单，但上线前为什么没想到？因为测试用例里压根没人会领21亿张券。

处理方式其实就三条路：扩大容量、提前检查、或者让它可控地坏。扩大容量最简单，int换long，long换BigInteger。但换类型有代价，内存翻倍，运算变慢，尤其在高频交易系统里，慢一纳秒都是钱。提前检查也常见，加个if判断，比如if(a > MAX - b) 就报错。这方法靠谱，但代码丑，每个加法和乘法都得包一层判断，写起来像在给每一行代码穿防弹衣。

还有个思路，是让溢出“不致命”。比如视频通话里的时间戳，用uint32存毫秒，每49.7天绕一圈。你没法避免它绕，但可以在检测到时间戳比上次小的时候，自动加上2^32再算。这叫“回绕补偿”。我见过一个老工程师这么干，他注释写“别问我为什么这么写，49天后你就懂了”。后来他离职了，新来的同事看到那段代码，以为是bug，删了补偿逻辑，结果系统运行到第50天，所有通话记录的时间全乱了。

真正难搞的是有符号整数溢出。C标准里说这是“未定义行为”，意味着编译器可以随便优化。你写了个检查溢出的代码，结果编译器觉得“反正int不会溢出，这检查永远为假”，直接给你删了。你说气不气。所以处理有符号溢出，你得用编译器内置函数，比如__builtin_add_overflow，它保证检测可靠，还生成高效代码。

但话说回来，90%的溢出问题都出在“没想过会这么大”。你设计一个计数器，觉得用户最多操作一万次，结果有人用脚本刷了百万次。你设计一个价格字段，觉得最多几万块，结果有土豪买了几十万的虚拟道具。程序员不是神仙，预判不了所有边界。

我的经验是：凡是外部输入能影响的值，一律按最坏情况设计。用户不会只点一下按钮，他会写个循环点一万下。网络包不会只有100字节，攻击者会发个65535字节的畸形包。别信“正常用户不会这么干”这种话，正常用户确实不会，但总有非正常用户，或者非正常的数据组合。

最后补一句，调试溢出问题时，别盯着代码逻辑死看。先打印出那个变量的值，看看它是不是负数、是不是小得离谱。多数时候，溢出不是“算错了”，而是“该换大容器的时候没换”。就像你拿个一次性纸杯去接消防栓的水，问题不在水压，在杯子的选择上。

(责任编辑：热点)