codepointat 按码点（逻辑字符）工作，charcodeat 按码元（utf-16 单元）工作；对四字节 unicode 字符如?、emoji，前者返回完整码点，后者返回代理对中的单个码元。
codePointAt 和 charCodeAt 都能获取字符编码，但它们处理 Unicode 的方式完全不同：前者按“码点”（逻辑字符）工作，后者按“码元”（底层 UTF-16 单元）工作。对 emoji、古汉字（如?）、中日韩扩展区字符等四字节 Unicode 字符，这个区别直接决定结果是否正确。
核心差异：码点 vs 码元
JavaScript 字符串内部用 UTF-16 编码。大多数字符占 1 个码元（16 位），但码点 ≥ U+10000 的字符（如 ?、?、??）需用两个码元组合表示，称为代理对（surrogate pair）。
-
charCodeAt(i) 只读取第 i 个码元的值，不管它是不是代理对的一部分。对?，
"?".charCodeAt(0)返回55362（高位代理），"?".charCodeAt(1)返回57271（低位代理）——两者单独看都没有字符意义。 -
codePointAt(i) 会自动检测代理对：只要 i 指向高位代理（0xD800–0xDFFF），它就合并前后两个码元，返回完整码点。例如
"?".codePointAt(0)直接返回134071（即 U+20BB7）。
实际使用中的关键行为
两者调用方式相同，但返回值和越界处理不同：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 索引超出范围时，
charCodeAt()返回NaN；codePointAt()返回undefined。 - 对普通 ASCII 或基本多文种平面（BMP）字符（U+0000–U+FFFF），两者结果一致，比如
"a".codePointAt(0) === "a".charCodeAt(0) === 97。 - 对代理对，
codePointAt(1)仍会返回低位代理的码元值（如 57271），这不是错误——它只是说明你调用了“第二个位置”，而该位置本身是代理对的后半部分；正确做法始终从代理对起始位置（即高位代理所在索引）调用codePointAt。
什么时候必须用 codePointAt
当你需要真实字符语义，而不是底层存储结构时：
- 统计字符串“视觉长度”：用
codePointAt遍历并跳过代理对第二单元，才能得到正确字符数。 - 提取或截取包含 emoji 的子串：基于
codePointAt判断字符边界，避免切在代理对中间导致乱码。 - 判断字符是否属于扩展 Unicode 区域：
str.codePointAt(i) > 0xFFFF是最简洁可靠的判断方式。 - 与后端或其他系统交换 Unicode 数据时，需确保传输的是完整码点而非孤立码元。
替代方案与配合建议
codePointAt 解决了编码获取问题，但不解决遍历问题：
- 想安全遍历每个逻辑字符？优先用
for...of或Array.from(str)，它们天然按码点迭代。 - 要获取指定位置的完整字符（不是单个码元）？用
Array.from(str)[i]或String.fromCodePoint(str.codePointAt(i))。 - 需要负索引取字符？用
str.at(-1)，比str.charAt(str.length - 1)更直观；但注意它仍按码元操作，对 emoji 不完全安全。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
