Java中char固定占2字节，是UTF-16基本单位，仅能表示BMP内字符（U+0000–U+FFFF）；超出BMP的字符（如emoji）需用代理对（两个char）表示，故str.length()≠字符数，应使用codePointCount等方法；char与byte转换必须经String+显式编码，不可直接强转。
char 固定占 2 字节，但不是“万能字符单元”
Java 中 char 是 16 位无符号整数，取值范围为 \u0000 到 \uffff（即 0–65535），在内存中始终固定占用 2 字节。它本质是 UTF-16 编码的基本单位，用于表示基本多语言平面（BMP）内的 Unicode 字符——比如英文字母、数字、常用汉字（如 '中'、'日'）、阿拉伯字母等。
但要注意：一个 char 并不能表示所有 Unicode 字符。像 ?、?、? 这类超出 BMP 的字符（码点 ≥ U+10000），Java 必须用两个 char 组成代理对（surrogate pair）来表示。此时单个 char 已无法完整承载语义，直接调用 charAt() 可能切开代理对，导致乱码或异常。
- 正确获取完整字符：用
String.codePointAt(int)和Character.charCount(int) - 避免错误操作：不要假设
str.length()等于字符个数（它返回的是 char 单元数，不是 Unicode 码点数） - 验证方式：
"?".length() == 2，但"?".codePointCount(0, "?".length()) == 1
String 内部存储不等于字节长度，编码决定最终大小
String 对象本身不“存字节”，它内部按 Unicode 逻辑组织字符。JDK 9+ 引入了紧凑字符串（Compact Strings）优化：若字符串只含 Latin-1 字符（码点 ≤ 255，如纯 ASCII），内部用 byte[] 存储，每个字符占 1 字节；一旦出现中文、emoji 等非 Latin-1 字符，就退回到 char[]（UTF-16），每个字符占 2 字节。
但这只是 JVM 的实现细节，不影响 getBytes() 的行为。真正决定网络传输或文件写入时字节数的，是显式指定的编码：
立即学习“Java免费学习笔记（深入）”；
-
"你好".getBytes(StandardCharsets.UTF_8)→ 长度为 6（每个汉字 UTF-8 占 3 字节） -
"你好".getBytes(StandardCharsets.UTF_16BE)→ 长度为 4（2 个字符 × 2 字节，无 BOM） -
"你好".getBytes(StandardCharsets.ISO_8859_1)→ 抛出异常（无法编码中文）
务必避免使用无参 getBytes()，它依赖系统默认编码（Windows 常为 GBK，Linux/macOS 多为 UTF-8），极易引发跨环境乱码。
char 与 byte 转换必须经过 String + 显式编码
char 本身不是字节，不能直接强转为 byte（(byte) '中' 会截断高位，得到错误值）。要获得其在某编码下的字节表示，必须走标准路径：
- 单个 char → 先转成长度为 1 的 String：
String.valueOf(c) - 再调用
getBytes(Charset)获取对应编码的字节数组 - 例如：
String.valueOf('中').getBytes(StandardCharsets.UTF_8)返回 3 字节数组
反向转换也需编码参与：从 byte[] 恢复 char，应先 new String(bytes, charset)，再用 charAt(0) 或 codePointAt(0) 提取——不能跳过 String 构造过程。
实际开发中的关键避坑点
很多问题源于混淆“内存布局”“逻辑字符数”和“序列化字节数”。几个高频陷阱：
-
文件读写未指定编码：用
FileReader/FileWriter（默认平台编码）读写 UTF-8 文件，中文必然损坏 -
数据库字段长度误判：MySQL 的
VARCHAR(10)在 utf8mb4 下最多存 10 个码点，但每个 emoji 占 4 字节，而 Java 中"?".length()返回 2 —— 容易超长插入失败 - JSON/HTTP 接口字节超限：API 限制 payload ≤ 10KB，若用 UTF-8 编码计算，中文占比高时实际能传的字符数远少于预期
-
日志或调试打印误导：
System.out.println("?".toCharArray().length)输出 2，容易误以为“占 2 字节”，其实 UTF-8 下它是 4 字节
核心原则：只要涉及二进制交换（IO、网络、序列化），就必须明确编码；只要处理用户可见文本，就该以 Unicode 码点为单位，而非 char 单元。
