System.arraycopy要求目标数组长度必须满足destPos + length ≤ dest.length，否则立即抛ArrayIndexOutOfBoundsException；它不扩容、不截断、不自动适配，且严格校验类型兼容性，需前置计算安全长度或改用Arrays.copyOf。
System.arraycopy 对目标数组大小有强依赖性，它不做扩容、不截断、不自动适配——目标数组必须提前配足空间，否则直接抛异常。
目标数组长度必须显式满足容量约束
arraycopy 不会检查“够不够用”，而是严格校验：destPos + length ≤ dest.length。只要越界，立刻抛 ArrayIndexOutOfBoundsException。这不是事后判断，而是在 native 层入口就拦截——意味着失败发生在真正搬运之前，没有隐式兜底。
- 比如目标数组长度为 10，想从索引 8 开始拷 3 个元素 → 8 + 3 = 11 > 10 → 报错
- 哪怕只拷 1 个元素，destPos 设为 10（数组最大索引是 9）→ 直接失败
- 它不关心源数组多长，只盯住目标侧的边界底线
不能靠 try-catch 来“兜底”，得靠前置计算
捕获 ArrayIndexOutOfBoundsException 是反模式。正确做法是复制前算出安全长度：
- 用 Math.min(src.length - srcPos, dest.length - destPos) 得到实际可拷的最大数量
- 若业务要求必须全量复制，应改用 Arrays.copyOf —— 它内部调 arraycopy，但先新建合适长度数组
- 在工具方法中，可提前校验 length > dest.length - destPos，并抛带上下文的 IllegalArgumentException，便于定位问题源头
类型匹配也绑定目标数组声明类型
目标数组不只是“要多大”，还决定“能装什么”。arraycopy 要求 src 和 dest 元素类型兼容：
- int[] 只能拷到 int[]，不能到 long[] 或 Integer[]
- String[] 可拷到 Object[]，反过来则报 ArrayStoreException
- 泛型擦除后调用（如 via Arrays.asList().toArray()）会破坏类型信息，导致 JIT 无法内联，性能反降
复用目标数组是优势，也是责任
正因为它不分配新数组，才快；但也正因如此，你得自己管好目标数组的生命周期和容量规划：
- 适合缓冲区循环使用场景（如网络包解析、RingBuffer 数据前移）
- 不适合“不确定长度”的动态拼接——此时 Arrays.copyOfRange 更安全
- 多线程写同一 dest 数组不同区域，仍需内存屏障或独立 buffer，arraycopy 自身不提供线程安全保证
