TL;DR
- 在撮合/风控/清算链路里，整数溢出会把“需要冻结一大笔钱”的计算绕回成小数甚至负数，直接导致资金校验失效、错误撮合、账本错乱。
- 别指望“多写几个 if 就行”：C/C++ 的有符号溢出可能触发 UB（未定义行为），编译器甚至会把你的边界检查优化掉；Go/Java 虽然行为确定（环绕），但业务上仍然是坑。
- 工程上要做的是纵深防御：入口范围校验 → 风控安全计算 → 撮合核心数值抽象 → 数据库类型兜底 → 独立审计对账，并把溢出当成“安全漏洞”来治理。
- 性能与安全可折中：热点路径用 checked/safemath + 严格范围证明；非实时路径（清结算/审计）可用 Decimal/big.Int 换取确定性与正确性。
1. 问题到底有多严重：溢出不是 Bug，是“资产安全洞”
交易系统里最可怕的一类事故，是“看起来只是数值计算出错”，但后果却是资金冻结/扣款/记账全部偏离。
溢出一旦把一个正数绕回成负数，就可能出现“买单反而不占用资金”的荒诞结果。
从结果看，它等价于：绕过风控 + 伪造成交成本 + 污染账本。
关键要点 / 常见坑（工程视角）
- 中间值溢出比最终值更危险：最终结果可能还在范围内，但中间乘法/缩放（price * qty * scale）早就爆了。
- 单位与精度没统一：价格用 10^-6，数量用 10^-8，路径里还混了“手动除回来”的逻辑；越写越像数学题，越容易踩边界。
- 把 float 当钱算：不一定溢出，但会引入 IEEE 754 误差、NaN/Inf 传播；对账时你会被 0.1+0.2 教做人。
- C/C++ 的 UB：有符号溢出未定义，编译器可能基于“不会溢出”的假设优化逻辑；线上出错时你很难复盘。
- 只修撮合不修风控/清算：入口放过一次，后面每一层都在“用错数做对账”，最后只能停机手工回滚。
2. 建议的纵深防线：把溢出治理贯穿整条链路
防溢出不该是散落的 if，而应当像安全工程一样分层：
入口层做“常识级”范围拒绝；风控层用安全算术计算冻结/保证金；
撮合核心用统一的定点/Decimal 类型封装钱与数量；
数据库用 DECIMAL/NUMERIC 做最后一道栅栏；
最后用独立审计对账服务做旁路复算，发现不一致就触发告警/熔断。
3. 数值类型选型：SafeMath / 定点 Decimal / big.Int 怎么用
- SafeMath（checked add/mul）：对 int64 做显式溢出检测，适合撮合热点路径，性能代价可控，但需要明确业务上界与边界测试。
- 定点 Decimal（int64 + precision）：统一钱/数量的表示（例如最小单位），避免 float；乘法后的 rescale/舍入策略要被当作业务规则写清楚。
- big.Int / 任意精度：几乎根治溢出，但会带来分配与 GC 压力；更适合清算、对账、审计等非纳秒敏感路径。
4. 适用场景：哪些团队现在就该把“溢出”拉到 P0
- 做撮合/风控/清算：任何涉及 price * qty、保证金、手续费、杠杆的地方都是高风险区。
- 支持多资产/多精度：外汇 4-5 位小数、加密 8-18 位小数，精度混用时中间值最容易炸。
- 从单体走向分布式：链路拉长后，错误会跨服务传播；没有对账旁路就等于“错了也不知道”。
- 做灰度/热升级：老逻辑与新逻辑同时存在时，数值口径不一致会放大对账与回滚成本。