charAt返回UTF-16代码单元而非Unicode码点，对BMP外字符需代理对表示；编码转换仅发生在字节与String构造间，charAt不参与编码处理。
charAt 方法本身不涉及字符集编码转换，它只按索引从字符串内部的 UTF-16 代码单元数组中取出一个 char 值。Java 的 String 在内存中始终以 UTF-16 编码存储，每个 char 对应一个 16 位代码单元——这意味着对 ASCII 或常用汉字（U+0000–U+FFFF）能一对一映射，但对超出 BMP 的字符（如部分 emoji、古文字），单个 char 无法完整表示，需用两个 char（代理对）联合表达。
charAt 返回的是代码单元，不是码点
String 底层是 char[] 数组，charAt(i) 实质就是返回该数组第 i 个元素。这个 char 是 UTF-16 的一个代码单元，不是 Unicode 码点。例如字符 "?"（U+1F600）在 Java 中占两个 char：高位代理（0xD83D）和低位代理（0xDE00）。若用 charAt(0) 取到的是 0xD83D，单独看没有对应可读字符；只有成对读取才能还原为真实码点。
要安全获取码点，应使用：
- String.codePointAt(int index)：返回指定位置开始的码点值（支持代理对）
- String.offsetByCodePoints(int index, int cpCount)：按码点数移动索引，避免切在代理对中间
- String.codePoints()：返回 IntStream，流中每个 int 是一个完整码点
编码转换发生在字节与字符串之间，不在 charAt 过程中
getBytes("UTF-8") 或 new String(bytes, "GBK") 这类操作才真正触发字符集编码/解码。charAt 完全不参与字节序列的解析或生成——它只工作在已构建好的 String 对象内部。也就是说：
立即学习“Java免费学习笔记（深入）”；
- 你用 UTF-8 读文件生成 String → 内部已转为 UTF-16 存储 → charAt 拿到的是 UTF-16 代码单元
- 你用 GBK 读文件生成 String → 解码时若发生乱码，String 内容本身就有误 → charAt 只是忠实地返回那个“错字”的 char
- charAt 不会把 char 再转成 UTF-8 字节，也不检查当前系统默认编码
常见误区：以为 charAt 能“看到”原始编码
有人误以为 charAt(0) 返回的 char 就是原始文本的“第一个字节对应的字符”，这是错的。比如：
- 字节序列
[0xE4, 0xB8, 0xAD]（UTF-8 的“中”）被 new String(bytes, "UTF-8") 构造后，String 内部存的是0x4E2D（一个 char） - 若错误地用
new String(bytes, "ISO-8859-1")构造，得到的 String 内容就变成三个独立 char：0xE4、0xB8、0xAD，charAt(0) 返回的是拉丁字母扩展字符，而非“中”
可见，charAt 的结果质量完全取决于 String 构造时解码是否正确，它自身不做任何编码判断或修正。
实际开发建议
处理中文、emoji 或多语言文本时：
- 遍历字符优先用 codePoints().forEach(...)，而不是 for + charAt
- 获取子串长度或截断位置时，用 String.offsetByCodePoints(0, n) 替代直接用索引加减
- 调试时可通过 String.codePointCount(0, length()) 查看真实字符数（可能小于 length()）
- 不要假设 char == 一个“人眼可见的字”，尤其在做前端显示截断、富文本光标定位等场景
