应在new int[n]前显式校验n≥0，因negativearraysizeexception在数组创建时立即抛出，无法靠try-catch补救；常见于未校验用户输入、配置值或计算结果（如list.size()-offset）等场景。
new int[n] 报 NegativeArraySizeException 怎么提前发现
这个异常只在数组创建时触发，JVM 不会等你写完逻辑再报错——new int[n] 一执行，n 是负数就立刻崩。所以不能靠 try-catch 补救，得在 new 之前拦住。
常见错误现象：从用户输入、配置文件、数据库查出一个数字（比如 config.getArraySize()），没校验直接传给 new int[size]；或者计算逻辑出错，比如 list.size() - offset 算出负数。
- 所有可能作为数组长度的变量，必须显式检查：
if (n - 不要依赖调用方保证，哪怕文档写了“返回非负”，也要自己判——Java 没契约检查
- 如果来自外部（如 HTTP 参数），用框架校验（如 Spring 的
@Min(0)）只是第一道防线，new前仍需再判一次，防止绕过校验路径
Stream.toArray() 和 ArrayList.toArray() 会不会抛这个异常
不会。这两个方法内部自己控制长度，你传进去的是集合或流，它们根据当前元素个数分配数组，不会把负数当长度用。
但注意陷阱：有人写 list.subList(from, to).toArray(new String[n])，这里的 n 如果是负数，就会触发异常——因为这是你手动传的数组引用，JVM 检查它的长度。
立即学习“Java免费学习笔记（深入）”；
-
list.toArray(new String[0])安全，推荐用这种零长数组写法 -
stream.toArray(String[]::new)也安全，工厂函数由 Stream 自己调用，传入正确大小 - 避免手写
new String[n]且n来源不可控
Arrays.fill()、Arrays.copyOf() 这类工具方法有没有类似风险
没有。这些方法不创建新数组（copyOf 除外），而是操作已有数组。真正有风险的是 Arrays.copyOf(T[] original, int newLength) —— 第二个参数 newLength 如果为负，会直接抛 NegativeArraySizeException。
容易被忽略的是：它和 new int[n] 触发的是同一个底层机制，只是栈上多了一层调用。
-
Arrays.copyOf(arr, arr.length + delta)中的delta必须确保结果 ≥ 0 - 不要假设
arr.length很大就忽略溢出，int 最大值是 2³¹−1，加法可能溢出变负 - 用
Math.addExact(a, b)替代普通加法，溢出会抛ArithmeticException，比静默变负更早暴露问题
为什么编译器不帮你检查数组长度是否可能为负
Java 编译器只做语法和类型检查，不追踪变量取值范围。即使你写了 int n = 5; new int[n];，它也不会去算 n 是不是恒正——更别说 n 来自方法返回值或运行时计算了。
静态分析工具（如 SpotBugs）能捕获部分明显问题（比如常量负数），但对分支逻辑、外部输入无能为力。
- 别指望 IDE 或 javac 提醒你，这事只能靠人盯住每个
new Type[...]和Arrays.copyOf(..., ...) - 单元测试里要覆盖边界值：0、1、Integer.MAX_VALUE、-1、以及任何可能让长度表达式为负的输入组合
- 如果项目用了 Lombok 的
@Builder或 Jackson 反序列化，注意字段注入后是否可能被设成负数——这类地方最容易漏校验
事情说清了就结束。最麻烦的不是写校验，而是那些藏在间接调用链里的长度计算，比如 A 调 B，B 调 C，C 返回一个数给 A 去 new 数组——中间任意一环算错，异常堆栈还只显示最外层的 new。
