Go整数溢出默认静默回绕而非panic，是性能优先的设计选择；math包Safe系列函数（如SafeAdd）提供显式检查，仅支持int64/uint64，需手动类型转换并分支处理。
Go 中整数溢出默认不 panic，但会静默回绕
Go 的整数类型（如 int、int64）在算术溢出时不会报错或中断，而是按补码规则自动回绕。比如 math.MaxInt8 + 1 得到 -128，不是错误，也不是 0 —— 这是底层硬件行为的直接暴露，不是 Go “设计失误”，而是明确选择：性能优先、控制权交还给开发者。
常见错误现象包括：计数器突然变负、时间戳计算错乱、循环次数异常跳变、哈希值碰撞率升高。尤其在处理用户输入、协议解析、索引计算时，极易中招。
- 使用场景：高频数值累加（如统计、滑动窗口）、基于 offset 的切片操作、二进制协议解析（字段长度/偏移量）、密码学相关计算（需显式模运算）
- 参数差异：
int溢出行为依赖运行时架构（32 位 vs 64 位），而int64等定长类型行为稳定，推荐在边界敏感逻辑中显式使用 - 性能影响：所有带溢出检查的运算（如
math.SafeAdd或自定义函数）都有轻微开销；纯回绕最快，但风险不可控
用 math 包的 Safe 系列函数做显式检查
math 包从 Go 1.21 起提供 SafeAdd、SafeSub、SafeMul、SafeNeg 等函数，返回结果和布尔值，真表示未溢出。
它们只支持 int64 和 uint64，不覆盖 int 或 int32 —— 别想当然传 int 进去，编译会报错。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式转换类型：
safe, ok := math.SafeAdd(int64(a), int64(b))，否则类型不匹配 - 不处理
int类型，因为其宽度不确定；若需检查int运算，先转成int64再调用，最后再判断是否仍在int范围内（用int64(math.MaxInt) >= safe） - 这些函数是内联的，性能接近原生运算，但多一次分支判断；对吞吐敏感路径（如网络包解析主循环），建议只在入口校验，非热路径可全量启用
if safe, ok := math.SafeAdd(x, y); ok {
result = int(safe)
} else {
return fmt.Errorf("integer overflow: %d + %d", x, y)
}手动实现 uint 回绕检测要小心截断陷阱
对 uint 类型，常用“减法反证法”检测加法溢出：a + b （因无符号回绕后必然变小）。但这只适用于 <code>uint，且前提是 a 和 b 都非负 —— Go 中 uint 天然满足，所以安全。
但注意：uint8(255) + uint8(1) == 0，此时 0 成立，检测正确；可一旦混入有符号类型（比如把 <code>int8(-1) 强转成 uint8），值变成 255，逻辑就乱了。
- 只对同类型
uint*使用a + b ，不要跨类型比较 - 避免在表达式里隐式提升：如
uint8(100) + uint16(100)会先升为uint16，再比较，但左边仍是uint8，类型不一致导致编译失败 - 测试边界时，务必覆盖最大值：如
uint32测0xffffffff + 1，别只测1 + 1
写单元测试必须覆盖 max/min 值组合
数值边界测试容易漏掉“刚好卡在临界点”的 case，比如 MaxInt64 - 1 和 2 相加会溢出，但 MaxInt64 - 2 和 2 就不会 —— 差 1 就是天壤之别。
Go 的 testify/assert 或标准库 testing 都行，关键是数据构造：不能只靠随机生成，得硬编码典型边界。
- 必测组合：
min + min、max + 1、max - 1 + 2、1 - max（对有符号）、0 - 1（检查负溢出） - 用
math.MinInt64、math.MaxUint32等常量，别手写-9223372036854775808，易错且难读 - 如果函数接受
interface{}或泛型参数，测试需覆盖每种具体类型，因为溢出行为随底层宽度变化
最麻烦的其实是“链式运算”：a + b * c 可能中间结果溢出，即使最终结果没溢出。这种得拆步验证，或者改用 big.Int —— 但那是另一层权衡了。
