预防长整型隐性溢出需前置检查：加法/乘法前按符号分治判断边界，优先使用Math.addExact等JVM级检测方法；警惕类型隐式截断，高频累加场景可结合阈值限流或BigInteger。
预防长整型隐性溢出，核心是把检查动作做在运算发生前，而不是等结果出来再判断对错。Java 中 long 溢出后不会报错，而是静默翻转成负数（比如 Long.MAX_VALUE + 1L 变成 Long.MIN_VALUE），这种错误极难被日志或断言捕获，必须靠前置逻辑拦截。
加法与乘法前必须做符号分治的边界判断
不能只用 a + b 这类事后验证——它漏掉大量负溢出场景（如两个大负数相加得正数），也不适用于混合符号运算。
- 加法检查逻辑（安全通用）：
若a > 0 && b > 0 && a > Long.MAX_VALUE - b→ 正溢出
若a → 负溢出 - 乘法检查更需谨慎：
先排除 0 和 ±1 等特例；再按符号组合分别判断：
正×正：若b != 0 && a > Long.MAX_VALUE / b
负×负：等价于正×正，取绝对值后同上
正×负 或 负×正：结果为负，检查是否小于Long.MIN_VALUE，即a （注意除法截断，建议用 <code>Math.multiplyExact替代手写）
优先使用语言级精确运算工具，而非手动兜底
Java 8+ 提供的 Math.addExact、Math.multiplyExact 等方法，底层调用 JVM 溢出检测指令，比手工判断更可靠、更少出错。
- 它们对
long参数直接生效，无需类型转换 - 溢出时抛
ArithmeticException，强制你设计明确的 fallback 路径（如降级、告警、切换 BigInteger） - 不适用于浮点或混合类型运算，但整型关键路径上应默认启用
警惕无符号语义误用和类型隐式截断
长整型溢出常被掩盖在类型转换中：
- 排序比较时写
(int)(a - b)（a、b是 long 时间戳）→ 差值超Integer.MAX_VALUE就翻转，排序全乱 - 数据库字段是 bigint，Java 用
int接收 → 服务启动时就截断，后续计算全错 - RPC 接口定义 long，但序列化框架因配置问题自动转成 int → 静默丢失高位
这类问题无法靠运行时检查发现，必须在接口契约、DTO 定义、SQL 映射层统一约束类型精度。
对高频累加场景，用 BigInteger 或预设阈值限流
不是所有 long 累加都适合用 Math.addExact —— 若数据源不可控（如日志行数、用户上报 PV），频繁抛异常反而影响可用性。
- 推荐策略：设定业务合理上限（如“单日 PV 不超过 100 亿”），累加前先比对当前值与阈值差值，超则拒绝或切到 BigInteger
- BigInteger 适合后台批处理、ID 生成器等非实时路径；避免在高频循环内反复构造新实例，复用
BigInteger.ZERO起始并链式调用add() - 注意：BigInteger 无溢出风险，但会带来 GC 压力和计算延迟，需权衡
