arrays.fill能填满基本类型数组，问题常出在引用类型共享、索引边界误解或扩容未赋值；copyof和copyofrange均遵循左闭右开规则，且均为浅拷贝。
Arrays.fill 为什么填不满基本类型数组？
它能填，但得填对“对象”——Arrays.fill 对基本类型数组（如 int[]、double[]）完全支持，但对包装类数组（如 Integer[]）也支持；真正容易出错的是「误以为它能改变原始数组引用」或「在未初始化的数组上乱填」。
-
fill操作的是原数组元素，不是副本，所以填完后原数组就变了 - 对
int[] arr = new int[5]执行Arrays.fill(arr, -1)，结果是[-1, -1, -1, -1, -1]，没问题 - 但若写成
Integer[] arr = new Integer[3]，再Arrays.fill(arr, 42)，会报NullPointerException吗？不会——因为fill直接赋值，42会被自动装箱为Integer，安全 - 真正翻车点：用
fill填String[]时传了null，比如Arrays.fill(strArr, null)是合法的，但后续如果没判空就调用.length()，运行时崩
Arrays.copyOf 和 copyOfRange 的边界怎么算才不丢数据？
两个方法都遵循「左闭右开」区间规则，from 能取到，to 取不到——这是绝大多数人第一次用就踩坑的地方。
-
Arrays.copyOf(arr, 3)：从arr[0]开始拷贝 3 个元素（即索引 0、1、2），新数组长度固定为 3 -
Arrays.copyOfRange(arr, 1, 4)：拷贝arr[1]、arr[2]、arr[3]，共 3 个元素，不是 4−1=3 个“位置差”，而是明确的元素个数 - 越界检查很严格：
from 或 <code>to > arr.length或from > to都会抛ArrayIndexOutOfBoundsException - 性能上，
copyOfRange内部调用System.arraycopy，比手动 for 循环快；而copyOf在新长度大于原长时，会用默认值补位（int[]补 0，String[]补null）
fill 和 copyOf 混用时，哪些组合是危险操作？
它们本身无害，但组合逻辑错位就会导致「看起来填了，其实没生效」或「复制了旧值，不是你想要的当前状态」。
- 先
fill再copyOf：安全，新数组拿到的是已填充后的值 - 先
copyOf再fill原数组：新数组不受影响，因为copyOf生成的是独立副本 - 危险组合：对同一个数组反复
fill+copyOfRange却忽略索引偏移。例如int[] src = {1,2,3,4,5}，执行Arrays.fill(src, 1, 3, 9)（填索引 1~2 为 9），再Arrays.copyOfRange(src, 0, 3)，得到的是[1,9,9]，不是全 9 —— 这不是 bug，是预期行为，但常被误读 - 更隐蔽的坑：用
copyOf扩容后忘记重新赋值引用，比如arr = Arrays.copyOf(arr, 10)必须显式赋值，否则扩容无效
基本类型 vs 引用类型，fill 和 copyOf 的行为差异在哪？
差异不在方法本身，而在 Java 数组的内存模型——fill 和 copyOf 都是浅拷贝，对引用类型只复制引用，不复制对象内容。
- 对
int[]：fill改的是数值，copyOf复制的是数值副本，彼此完全隔离 - 对
String[]：fill把每个槽位设为同一个字符串引用；copyOf复制的是这一串引用，新旧数组指向相同的String实例（String不可变，所以通常没事） - 对自定义对象数组
Person[]：Arrays.fill(people, new Person("A"))会让所有元素指向**同一个**Person实例；修改其中任意一个的字段，其他全跟着变——这才是最易被忽略的深坑 - 要避免这个陷阱，得手动循环创建新对象，或者用
Stream.generate(() -> new Person()).limit(n).toArray(Person[]::new)
填数组不是填表格，fill 和 copyOf 看似简单，但一旦涉及引用共享、索引边界、扩容赋值，就很容易在调试时发现“我明明填了，怎么还是旧值”。关键不是记方法签名，而是盯住「谁在改谁」「引用是否复用」「边界是否闭合」这三点。
