NegativeArraySizeException 是 JVM 对负数组长度的被动拦截，非主动防护机制；应前置校验尺寸合法性，而非依赖其暴露 Bug。
NegativeArraySizeException 是 Java 运行时抛出的 unchecked 异常，当代码试图用负数作为数组长度创建数组时触发（例如 new int[-1]）。它本身不是防御机制，而是 JVM 对非法操作的自然拦截。你不能“利用”它来主动阻止逻辑 Bug，但可以借助它的触发时机，**暴露、定位并修正**本该在申请前就被拦截的负尺寸计算逻辑。
理解它的本质：被动信号，不是主动防护
这个异常是 JVM 的安全兜底，不是设计用来做输入校验的。依赖它来“阻止 Bug”，等于让程序先出错再修复——属于事后补救，而非事前预防。真正可靠的方案，是在创建数组前就验证尺寸表达式的合法性。
把异常变成调试线索：快速定位计算源头
当 NegativeArraySizeException 抛出时，堆栈会明确指出哪一行调用了 new。顺着这行向上查：
- 检查该数组长度变量（如
size）来自哪里：是用户输入？是集合.size()运算结果？是两个整数相减（如end - start）？ - 重点审查涉及减法、缩放、边界计算的表达式——它们最容易溢出或产生负值。
- 添加临时日志或断点，打印参与计算的原始值（如
end=5, start=10），确认是否逻辑反了。
前置校验：用 if 判断代替依赖异常
在 new 数组之前，显式检查尺寸是否合法：
-
错误做法：直接
new byte[calculateLength()]，寄望异常捕获后处理。 -
正确做法：
int len = calculateLength(); if (len < 0) { throw new IllegalArgumentException("Invalid array length: " + len); } byte[] buf = new byte[len]; - 对可能溢出的运算（如大数相乘），使用
Math.multiplyExact或Math.addExact，它们会在溢出时抛ArithmeticException，比负长度更早暴露问题。
从根源避免负长度：设计阶段的注意事项
很多负长度源于不严谨的边界处理：
- 用
Math.max(0, end - start)替代裸减法，确保非负（但需确认截断是否符合业务语义）。 - 处理用户输入或外部数据时，始终假设其不可信，做范围校验（如长度应在 [0, MAX_BUFFER_SIZE] 内）。
- 在流式处理或分页逻辑中，避免用
list.subList(from, to)后直接取.size()作数组长度——若to ，子列表为空但不会报错，后续计算可能出问题。
