char[]转String应使用new String(charArray)构造器，它安全拷贝数组生成不可变String；String转char[]唯一标准方式是toCharArray()，返回与原字符串解耦的副本。
char[] 转 String：别直接拼接，用 String 构造器最稳
Java 里把 char[] 变成 String，最常用也最安全的方式就是调用 String 的构造器：new String(charArray)。它会拷贝数组内容，生成一个不可变的 String 实例。
常见错误是手动用 StringBuilder 拼接或循环加 +，既慢又没必要；更危险的是误以为 String.valueOf(charArray) 和构造器行为完全一样——其实它底层确实调用了构造器，但语义上更偏向“转义值”，可读性稍弱，且在空数组时行为一致，但团队代码风格统一建议优先用构造器。
- 如果数组可能为
null，必须先判空，否则抛NullPointerException - 想截取部分字符？用带 offset 和 length 的重载：
new String(charArray, 2, 5) - 不要用
String.copyValueOf(charArray)—— 它和构造器功能几乎一样，但命名易误解（暗示“复制值”，实际也是拷贝），且 JDK 9+ 内部已优化为同路径，没必要多记一个 API
String 转 char[]：toCharArray() 是唯一标准方式
从 String 拿出字符数组，只该用 toCharArray()。它返回一个新分配的 char[]，内容与原字符串一致，且与原 String 完全解耦。
有人试过反射访问 String 内部的 value 字段，或者用 String.getBytes(StandardCharsets.UTF_8) 再转回来——这些要么破坏封装、要么引入编码误差、要么性能更差，一律不推荐。
立即学习“Java免费学习笔记（深入）”；
-
toCharArray()返回的是副本，修改它不会影响原String（这点很重要，尤其在传参或缓存场景） - 别用
String.toCharArray().clone()—— 多此一举，toCharArray()本身已返回新数组 - 如果只是想遍历字符，优先用
for (int i = 0; i ，避免无谓分配数组
性能与内存：小字符串无感，大数组要注意拷贝开销
每次调用 toCharArray() 或 new String(charArray) 都涉及一次数组拷贝。对几 KB 以内的字符串，JVM 优化足够好，感知不到；但若处理 MB 级日志块或批量解析大文本，频繁互转就容易成为瓶颈。
典型踩坑场景：在循环里反复 str.toCharArray() → 修改 → new String(modifiedArray)，结果内存飙升、GC 增多。
- 如果只是读取、不修改，别转数组，直接用
charAt()或codePointAt() - 如果必须修改字符内容，且后续还要当
String用，考虑是否能用StringBuilder替代数组操作 - JDK 9+ 的
String内部改用byte[]存储（配合编码标识），但toCharArray()行为完全透明，无需关心底层变化
编码陷阱：char[] 本身不带编码信息，别和字节混淆
char[] 是 UTF-16 编码的 Unicode 码元序列，不是字节。它和文件读写、网络传输里的 byte[] 不是一回事。误把 char[] 当作 UTF-8 字节去发 HTTP 请求，或拿 new String(bytes) 的结果再 toCharArray()，极易出现乱码。
典型错误现象：new String("你好".getBytes("GBK")) 在非 GBK 环境下变成乱码，再转回 char[] 已无法还原。
- 涉及 IO 或协议交互时，明确区分
char[]（文本逻辑层）和byte[]（传输层） - 需要编码转换？走标准路径：
string.getBytes(Charset)→new String(bytes, Charset)，中间不插char[] - 正则、
String.split()、Character.isLetter()这些 API 全部基于char或 code point，和字节编码无关
