char类型能存一个中文字符仅限BMP平面内，因Java中char是UTF-16编码单位（2字节），BMP字符如“中”直接存储，而增补平面字符（如U+1F926）需两个char组成的代理对表示。
char 类型能存一个中文字符，但前提是这个字符在 BMP（基本多文种平面）范围内——绝大多数常用中文字符（如“中”“文”“编”“程”）都满足，没问题；而少数生僻字、emoji、历史汉字可能落在增补平面（如 U+20000 以上），这时单个 char 就存不下，必须用两个 char（即代理对）。
为什么 char 看似 2 字节却有时存不下一个“字符”
Java 的 char 是 UTF-16 编码单位，固定占 2 字节（0x0000–0xFFFF），但它不直接等于“Unicode 字符”。Unicode 字符集里有超过 100 万个码位，UTF-16 用两种方式表示：
- BMP 内的字符（U+0000–U+FFFF）：直接用一个
char表示，比如'中'对应0x4E2D - 增补字符（U+10000–U+10FFFF）：拆成两个
char，高位代理（0xD800–0xDBFF）+ 低位代理（0xDC00–0xDFFF），合起来才表示一个逻辑字符
所以不是“char 不支持中文”，而是“char 不一定代表一个用户感知的字符”。比如字符 ''（U+1F926，面部按摩 emoji）在 Java 中长度为 2，"'.length() 返回 2，charAt(0) 拿到的是高位代理，单独打印会是 。
判断一个字符是否能被单个 char 安全表示
别看字面值，要看它的 Unicode 码点。实际编码中，用 Character.isBmpCodePoint(int) 或手动检查范围更可靠：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
Character.codePointAt("中", 0)→ 返回0x4E2D（≤ 0xFFFF），可单char -
Character.codePointAt("", 0)→ 返回0x1F926（> 0xFFFF），需代理对 - 别用
str.charAt(i)遍历字符串取“字符”，改用str.codePointAt(i)+Character.charCount(cp)跳位
常见踩坑：用 for (int i = 0; i 处理含 emoji 或生僻汉字的字符串，会导致高位代理被当普通字符处理，后续拼接或比较出错。
字符串长度、截断、正则匹配时的实际影响
String.length() 返回的是 char 个数，不是 Unicode 字符个数。这直接影响：
- 截断：
s.substring(0, 5)可能切在代理对中间，导致末尾出现 - 索引操作：
s.charAt(3)可能返回一个孤立的代理码元，无法还原原字符 - 正则：
".".matches(".")中的.默认只匹配单个char，对增补字符会失配；得用(?s).或\X（Unicode 字符边界） - IO 和序列化：写入文件或 JSON 时，若目标格式不支持代理对（如某些旧版数据库字段），可能丢数据或报错
真正需要按“人眼字符”计数或操作时，优先用 String.codePoints() 流，或者 Character.toCodePoint(char hi, char lo) 手动合成。
Unicode 字符和 Java char 的映射不是一对一，这个断层在处理用户昵称、评论、古籍 OCR 文本时特别容易暴露——你以为截前 10 个字符很安全，结果第 10 个刚好是某个生僻字的高位代理。
