String.codePointAt() 对表情符号返回“错的值”是因为表情符号多为Unicode补充字符，以UTF-16代理对存储，而该方法按索引操作：若索引指向低代理码元（如0xDC00），会直接返回其值而非完整码点；需结合isSurrogatePair判断或用codePoints()遍历。
String.codePointAt() 为什么对表情符号经常返回“错的值”
因为很多表情符号（比如 ?、??、?️?）是 Unicode 补充字符（U+10000 以上），在 Java/JavaScript 中以两个 UTF-16 代理对（surrogate pair）形式存储。而 String.codePointAt() 的参数是**索引位置**，不是“字符位置”——如果你传入一个代理对中后半部分的索引（比如 str.codePointAt(1)），它会直接返回那个低代理码元（如 0xDC00 级别的值），而不是整个表情的码点。
必须配合 Character.isSurrogatePair() 或手动跳过代理对
正确遍历含表情的字符串，不能简单用 i++ 增量索引。要判断当前位置是否为高代理（0xD800–0xDBFF），且下一位是否为低代理（0xDC00–0xDFFF），是则合并计算，否则单字符处理：
for (int i = 0; i < str.length(); ) {
int cp = str.codePointAt(i);
// 处理 cp（即真实 Unicode 码点）
i += Character.charCount(cp); // 关键：用 charCount 跳过 1 或 2 个 char
}
-
Character.charCount(cp)返回该码点需要几个char单元（1 或 2），比手写if (cp > 0xFFFF) i += 2 else i += 1更安全 - 直接用
str.codePointAt(i)+i++会导致低代理被单独解析，结果变成无效码点（如56320对应\udc00） - Java 9+ 可用
str.codePoints().forEach(...)替代手动循环，但底层仍依赖相同逻辑
JavaScript 中 String.codePointAt() 的行为差异
JS 的 String.prototype.codePointAt() 设计更友好：只要传入合法索引（即使指向低代理），它会自动向前检查并返回完整码点；若索引指向低代理且前面不是高代理，则返回 undefined。但仍需注意：
- 不要假设
str.length等于“字符数”——"??".length === 4，但只有 1 个码点 - 用
Array.from(str)或[...str]才能得到按码点分割的数组，避免代理对被拆开 -
"?".codePointAt(0)返回128077（✅），但"?".codePointAt(1)返回undefined（✅），不是乱码
常见误用场景与调试建议
当发现表情显示为空白、方块，或日志里出现 55357、56320 这类数值，基本可断定是把代理码元当成了有效码点。排查时重点看：
- 是否用
for (int i = 0; i 循环后直接调 <code>s.codePointAt(i) - 是否把
char类型变量（而非int）用于接收codePointAt()结果（会截断高位） - 是否在 JS 中用
str[i]取值后再传给codePointAt()（str[i]是单个 UTF-16 单元，已丢失上下文）
真正麻烦的不是函数本身，而是默认把字符串当“单字节字符数组”来索引的思维惯性——Unicode 字符长度不固定，这个事实得刻进循环条件里。
