计数器溢出必然发生，关键在于何时发生；常见于定时器计数、数组下标计算、队列/栈满空判断三处，需通过边界测试（如0、最大值、最大值+1）和防御性编码（如显式回绕、计数器法、输入校验）主动防控。
数据结构里的计数器溢出，不是“会不会发生”的问题，而是“什么时候发生”的问题。很多初学者写完代码跑通了几个用例就以为没问题，结果上线后在某个看似平常的时刻突然崩掉——比如第198天、第100000次入队、第2147483647次计数。根源不在逻辑错，而在边界没想全。
计数器溢出最常藏身的三个位置
它不总出现在你盯着看的循环里，而更爱躲在这些地方：
- 定时器/心跳计数：32位无符号整型最大值是4294967295，若每毫秒加1，约49.7天就回绕；若每秒加1，约136年才溢出；但若每10毫秒加1（常见嵌入式节拍），刚好198天就绕回0——这就是Y4G危机的源头
-
数组下标与长度计算：比如
int idx = (head + count) % size，当count极大时，head + count先溢出，再取模就完全失真 - 队列/栈容量判断：用头尾指针相等判空，又用同一条件判满，就会混淆状态；必须预留一个空位、或引入计数器、或加标志位，否则一到临界点就行为不可控
边界测试不能只靠“试试看”
真实系统崩溃前，往往没有任何报错日志，就像Y4G那次——只有看门狗超时，连堆栈都干净。这意味着靠运行时观察根本发现不了问题。必须主动设计边界用例：
- 对所有整型计数器，至少验证：0、1、最大值-1、最大值、最大值+1（回绕后值）
- 对队列/栈，必须覆盖：空、仅1个元素、满（含临界满）、满+1（尝试溢出操作）
- 对时间相关计数，换算成实际运行时长：比如32位毫秒计数器 → 约49.7天；32位秒计数器 → 约136年；别假设“我这辈子遇不到”
防御性编码的几条硬规则
边界不是加个if就万事大吉，关键在设计阶段就把它当成接口契约：
- 所有计数变量声明时，明确标注语义和预期范围，例如
// uptime_ms: wraps every ~49.7 days, use uint32_t - 涉及加减运算的计数，优先使用带溢出检查的算术（如GCC的
__builtin_add_overflow）或显式回绕处理（val = (val + 1) & MASK） - 栈/队列的满/空判断，统一采用“计数器法”——额外维护
size字段，比指针推演更直观、更难出错 - 任何外部输入参与计数（如网络包序号、用户ID、文件行号），必须做范围校验，不能默认“输入合法”
边界感是一种肌肉记忆
它不是某天突然学会的，而是在一次次修复Segmentation Fault、排查“为什么刚满就报错”、重读自己三个月前写的for (i = 0; i 中慢慢长出来的。当你看到<code>int i第一反应是“它能到多大”，看到buffer[256]本能想“第256个字节写进去会怎样”，你就真正跨过了那道门槛。
