String.getChars 更省内存因其不创建新数组，仅向已有char[]填充数据；而toCharArray()每次新建数组再复制全部内容。
String.getChars 为什么比 toCharArray + Arrays.copyOf 更省内存
因为 getChars 不创建新数组，只往你已有的 char[] 里填数据；而 toCharArray() 每次都 new 一个数组，哪怕你只要其中几个字符，也得先复制全部再切片。
适合场景：高频字符串解析（比如日志行逐字段提取）、循环中反复处理子串、GC 敏感环境（Android 或低配服务端）。
- 参数顺序容易记反：
srcBegin是字符串起始下标，dstBegin是目标数组起始下标，不是“长度”也不是“偏移量” - 下标越界不抛
IndexOutOfBoundsException？错——它会在运行时检查，但只检查srcBegin和srcEnd是否合法；如果dstBegin + (srcEnd - srcBegin) > dst.length，才抛ArrayIndexOutOfBoundsException - 注意：
srcEnd是**不包含**的右边界，和substring(int, int)一致，不是长度
示例：
String s = "hello world";<br>char[] buf = new char[5];<br>s.getChars(0, 5, buf, 0); // buf 变成 ['h','e','l','l','o']
getChars 在 substring 频繁调用时的实际性能陷阱
很多人以为“避免创建新数组=一定快”，但现实是：如果目标数组每次都要 new，或者复用逻辑混乱，getChars 反而更慢。它的优势只在「固定缓冲区反复写入」场景成立。
立即学习“Java免费学习笔记（深入）”；
- 别在循环里每次 new
char[256]再传给getChars——对象分配开销抵消了复制收益 - 如果字符串极短（如 toCharArray 可能被内联+逃逸分析优化掉，实测未必比
getChars快 - HotSpot 8u202+ 对
getChars做了 intrinsic 优化，但仅限于数组访问不越界且长度可静态推断的情况；动态计算的srcEnd会退化为普通方法调用
和 getBytes、toCharArray 的兼容性差异
getChars 是纯 Unicode 码元复制，不做编码转换；而 getBytes(String charset) 依赖字符集，toCharArray() 返回的是内部 char[] 的副本（Java 9+ 是不可变底层数组，但语义上仍是副本）。
- 遇到代理对（surrogate pair）：
getChars按char单位复制，不会自动合并成int码点；想正确处理 emoji 或中文古字，得配合String.codePointAt手动遍历 - Java 9 引入压缩字符串（compact strings），底层可能是
byte[]+coder标志；getChars内部会按需解压，但这个过程不可见——你只需确保目标数组够大 -
toCharArray()返回的数组内容和getChars完全一致（同字符串、同范围），只是多了一次分配
容易被忽略的 null 安全与空字符串边界
getChars 不接受 null 字符串，也不检查目标数组是否为 null——它直接开始复制，所以 NullPointerException 会在第一行数组写入时抛出，堆栈不指向 getChars 而是指向你的 buf[i] = ... 行（如果你反编译看 hotspot 源码就能理解）。
- 空字符串
""调用getChars(0, 0, buf, 0)是合法的，什么也不做，不抛异常 - 但
getChars(0, 1, buf, 0)在空字符串上会立即抛StringIndexOutOfBoundsException - 别依赖 IDE 的自动补全提示来判断参数合法性——IntelliJ 显示的参数名是
srcBegin/srcEnd，但文档里写的 “the beginning and ending indexes” 容易让人误以为srcEnd是“结束位置索引”，其实是“第一个不复制的位置”
真正麻烦的是跨模块传递 char[] 缓冲区：谁负责清空、谁保证长度、越界时是静默截断还是炸掉——这些都不在 getChars 的契约里，得靠约定或封装。
