Java数值溢出无法在编译期捕获，因javac仅检查语法、类型安全及部分常量范围，不分析运行时语义；防御应依赖Math.exact方法、long默认类型、静态分析工具等运行时与开发阶段防护措施。
Java 的数值溢出无法在编译期捕获——这是语言规范决定的，不是疏漏，也不是工具链能绕过的限制。
为什么编译器不报溢出错误
Java 编译器（javac）只检查类型安全、语法合法性和部分常量表达式范围，但不执行运行时语义分析。比如：
-
int x = Integer.MAX_VALUE + 1;—— 这行代码在编译期是合法的，因为它是常量表达式，且 javac 允许它“静默回绕”，结果就是-2147483648； -
int a = 1000, b = 1000; int c = a * b;—— 编译器不追踪变量值，所以不会预警a * b是否溢出； - 哪怕写成
final int a = 1000000; final int b = 1000000; int c = a * b;，只要乘积未超int范围，就通过；一旦超限（如50000 * 50000），javac 仍允许，运行时才回绕。
能做编译期检查的有限场景
仅对编译期常量表达式（compile-time constant expressions）做简单截断检查，且仅限赋值语句：
-
byte b = 128;→ 编译报错：可能损失精度（128 超出byte范围）； -
short s = 32768;→ 同样报错； - 但
int i = 2147483647 + 1;不报错，因为 Java 明确允许该常量表达式按int规则回绕； -
final int x = 2147483647; int y = x + 1;也不报错——x是常量，但x + 1不再被当作“编译期常量赋值”来校验溢出。
真正可行的防御路径
放弃“编译期捕获”的幻想，转向开发阶段主动拦截和运行时显式防护：
立即学习“Java免费学习笔记（深入）”；
- 用
Math.addExact()、Math.multiplyExact()等替代裸运算，溢出时抛ArithmeticException，失败即知； - 外部输入（如字符串转数字）先走
Long.parseLong()再比对Integer.MIN_VALUE/MAX_VALUE，别依赖parseInt()的异常兜底； - 累加、计数、索引、时间差等场景，默认用
long声明变量，避免过早收缩到int； - 在 CI 流程中接入 SpotBugs 或 ErrorProne 插件，它们能静态扫描出高风险模式（如
int循环变量与MAX_VALUE比较、隐式截断转换），虽非编译器原生能力，但效果接近“增强编译期检查”。
不要踩的坑
以下操作看似“提前检查”，实则无效或更危险：
-
int x = (int)(Integer.MAX_VALUE + 1L);—— 先以long算出2147483648L，再强转成int，结果仍是-2147483648，溢出已发生； -
if (a > Integer.MAX_VALUE - b) { /* 防溢出 */ }—— 对负数失效，且Integer.MAX_VALUE - b本身可能先溢出； - 依赖 IDE 高亮或 Linter 提示“潜在溢出”——那只是启发式警告，不可信为确定性保障。
