java string底层用byte[]存储，但不直接以utf-8编码，而是根据内容自动选择latin-1（coder=0）或utf-16（coder=1）编码；utf-8仅在显式转换时使用。
Java 中的 String 底层确实使用 byte[] 存储（自 Java 9 起默认启用紧凑字符串优化），但它**不直接以 UTF-8 编码存储字符**，而是根据内容自动选择 Latin-1（单字节）或 UTF-16（双字节）编码格式。UTF-8 是外部编码协议，仅在序列化（如写入文件、网络传输）时按需转换。
底层 byte 数组的编码逻辑
Java 9+ 的 String 内部用一个 byte[] value 加一个 byte coder 字段协同工作：
- coder == 0：表示 Latin-1 编码，每个字符占 1 字节，适用于纯 ASCII 或 ISO-8859-1 字符（如英文字母、数字、常见符号）
- coder == 1：表示 UTF-16 编码，每个字符占 2 字节（BMP 字符），补充字符（如 emoji、古汉字）则用代理对（4 字节）
这个选择在字符串创建时静态决定，且不可变。例如：new String("abc") → Latin-1；new String("αβγ") → UTF-16；new String("??") → UTF-16（含代理对）。
UTF-8 编码只发生在显式转换时
String 本身不“支持 UTF-8 存储”，但提供标准方法按需生成 UTF-8 字节序列：
-
str.getBytes(StandardCharsets.UTF_8)：返回 UTF-8 编码的byte[]，长度可能 ≠ 字符数（如 "é" 在 UTF-8 中占 2 字节） -
new String(bytes, StandardCharsets.UTF_8)：将 UTF-8 字节安全还原为字符串（前提是 bytes 确实是合法 UTF-8） - 注意：
str.getBytes()（无参）依赖平台默认编码，不是 UTF-8，应避免使用
为什么不用 UTF-8 作为内部编码？
主要出于性能与通用性权衡：
- 随机访问开销大：UTF-8 是变长编码，获取第 n 个字符需从头解析，而 UTF-16（BMP 内）和 Latin-1 支持 O(1) 索引
- 内存与 CPU 平衡：Latin-1 对 ASCII 文本节省 50% 内存；UTF-16 对多数常用 Unicode 字符（BMP）保持定长，兼顾空间与访问效率
-
生态兼容性：Java 原生 API、JVM 指令（如
charAt）、JNI 接口均基于 UTF-16 语义设计
实际开发中的关键提醒
理解底层存储不影响日常使用，但影响字节操作的正确性：
- 不要假设
string.length()==string.getBytes(UTF_8).length（中文字符通常 1→3，emoji 可能 1→4） - 文件读写、HTTP body、数据库字段等涉及字节流场景，必须显式指定
StandardCharsets.UTF_8 - 调试时可通过
string.getBytes(UTF_8)查看真实 UTF-8 编码，而非依赖string.getBytes()
本质上，String 的 byte 数组是实现细节，UTF-8 是通信契约——两者各司其职，配合使用即可。
