防止arithmeticexception的核心是避免运行时非法算术操作，主要通过除数/模数判零、封装安全运算工具、区分整数与浮点语义、结合静态分析和单元测试覆盖边界值来实现。
防止 ArithmeticException 的核心是**避免在运行时执行非法算术操作**，最常见的是除零和对整数执行模零运算。Java 在整数除法（/）和取模（%）中遇到除数为 0 时会立即抛出该异常；浮点数（float/double）则不会（结果为 Infinity 或 NaN），但需注意业务逻辑是否可接受。
检查除数和模数是否为零
这是最直接、最有效的预防手段。在执行 / 或 % 前，显式判断操作数是否为 0：
- 对整数类型（
int,long,short,byte）必须检查； - 若除数来自用户输入、配置、数据库或外部 API，更要默认视为不可信，强制校验；
- 示例：if (divisor != 0) { result = dividend / divisor; } else { throw new IllegalArgumentException("除数不能为零"); }
使用断言或工具类封装安全运算
在开发/测试阶段可用 assert 快速暴露问题（注意：生产环境默认禁用）；更稳妥的方式是封装工具方法，统一处理边界逻辑：
- 定义
SafeMath.safeDivide(int a, int b)，内部先判零，再返回结果或抛定制异常/返回 Optional； - 配合 Lombok 的
@NonNull或 Spring 的@Valid对入参做前置校验，把问题拦截在进入运算逻辑之前； - 避免在循环或高频调用路径中重复写判空判零，封装一次，复用多处。
区分整数与浮点数的语义差异
不要因“浮点数不抛 ArithmeticException”就随意混用。例如：
- 计数、索引、分页参数等天然应为整数，用
double反而引入精度误差和逻辑歧义； - 若业务允许“无穷大”或“未定义”，且明确需要浮点行为，才选用
double并配套处理Double.isInfinite()和Double.isNaN()； - 多数金融、统计、分页场景仍应坚持整数运算 + 显式零值防护。
借助静态分析与单元测试覆盖边界值
人工检查易遗漏，尤其在重构或多人协作时：
- 启用 IDE（如 IntelliJ）或 SonarQube 的算术零检测规则，自动标出潜在风险行；
- 单元测试中必须包含
divisor = 0、divisor = -1（尤其涉及Integer.MIN_VALUE / -1的溢出场景）、极小/极大值等用例； - 用
JUnit 5的@ParameterizedTest驱动多组边界数据，确保防护逻辑真正生效。
