size_t下溢反向遍历不会崩溃因无符号回绕为SIZE_MAX，但导致无限循环；时间戳差值利用无符号减法模运算特性，溢出反而是正确feature，前提是类型统一且不单独判回绕。
用 size_t 下溢做反向遍历索引时，为什么 i-- 不会崩溃但逻辑可能错？
因为 size_t 是无符号类型，i-- 在 i == 0 后不会变成 -1，而是回绕成 SIZE_MAX（如 64 位系统下是 18446744073709551615）。这本身不触发未定义行为，也不崩溃，但会导致循环继续执行——你本想遍历到索引 0 就停，结果它从 0 跳到最大值，再一路减到 1，最后又回到 0，无限循环。
常见误写：
for (size_t i = vec.size(); i >= 0; --i) { /* 错！i >= 0 永远为真 */ }真正安全的写法是避开 0 作为终止点：
- 改用
for (size_t i = vec.size(); i > 0; --i) { use(vec[i-1]); } - 或用有符号类型：
for (int i = static_cast<int>(vec.size()) - 1; i >= 0; --i)</int> - 更推荐用迭代器：
for (auto it = vec.rbegin(); it != vec.rend(); ++it)
unsigned int 时间戳差值计算中，溢出非 bug 而是 feature？
在嵌入式或性能计时场景（如 nRF52832 的毫秒计数器），用 uint32_t 存时间戳，49.7 天就回绕一次。但只要所有差值计算都用无符号减法，结果天然正确：
立即学习“C++免费学习笔记（深入）”；
uint32_t start = 0xFFFFFFFE; uint32_t end = start + 10; // → 8 uint32_t delta = end - start; // → 10，不是 -4294967286
这是因为无符号减法等价于模运算：(a - b) % UINT32_MAX。只要 end >= start 或者 end 是 start 之后自然增长的结果（哪怕已回绕），差值就恒等于真实经过的 tick 数。
注意前提：
- 必须全程使用同一无符号类型（不能混用
int和uint32_t） - 不能对单个时间戳值做“是否回绕了”的判断（比如
if (now ），那不可靠 - 差值跨度不能超过类型能表示的最大正差（即不能跨两次回绕，否则
end - start会小于真实值）
什么时候该主动依赖无符号溢出，而不是拼命防溢出？
只有两个明确场景值得把无符号溢出当工具用：
-
环形缓冲区索引：用
size_t head = (head + 1) % capacity不如直接++head，然后靠自然溢出实现 wrap-around（前提是capacity是 2 的幂，且你用位掩码& (capacity - 1)提取低位） -
哈希/校验和累加：如 CRC、FNV 等算法明确要求模 2ⁿ 运算，此时
uint32_t sum += x的溢出就是标准行为，无需检查
其余所有情况——尤其是涉及用户输入、配置项、循环计数、内存分配大小——都应视为潜在错误源。别幻想“我懂它怎么溢出，所以能利用”，编译器优化（如 -O2）可能重排或删掉你依赖溢出的逻辑分支。
__builtin_add_overflow 和无符号溢出检测，到底要不要用？
要。即使你认为某处“应该”利用无符号溢出，也建议仍用 __builtin_add_overflow 显式检测并处理边界。原因很实际：
- 它对
unsigned和signed都有效，语义统一 - 比手写条件（如
a > UINT_MAX - b）更不易出错，尤其对复合表达式 - Clang/GCC 都支持，生成的汇编通常就是一条带进位标志的加法指令，零开销
示例：
uint64_t a = ..., b = ...;
uint64_t result;
if (__builtin_add_overflow(a, b, &result)) {
// 处理溢出：抛异常、截断、转大数等
return std::nullopt;
}
return result;真正容易被忽略的点是：**无符号溢出虽定义良好，但业务语义上几乎总是非法的**。时间戳差值是个例外；其余多数时候，溢出意味着数据超限、配置错误或攻击输入——该拦住，不该“巧妙利用”。
