codePointAt() 更适合处理 Emoji，因其能正确识别 UTF-16 代理对并返回完整 Unicode 码点（如 128104），而 charCodeAt() 仅返回单个码单元，会将一个 Emoji 拆成两个错误值；安全遍历需用 for 循环配合 codePointAt()，遇高位代理（0xD800–0xDFFF）则跳过下一索引。
codePointAt() 为什么比 charCodeAt() 更适合处理 Emoji
因为大多数 Emoji（如 ??、?、??）是 Unicode 高位码点（U+10000 及以上），在 JavaScript 中以 UTF-16 代理对（surrogate pair）形式存储：占两个 char，但逻辑上是一个字符。而 charCodeAt() 只返回单个 UTF-16 码单元（0–65535），遇到代理对会拆成两个错误的“字符”；codePointAt() 则能识别代理对并返回完整的 Unicode 码点值（如 codePointAt(0) 对 "??" 返回 128104），这才是真正语义上的“第几个字符”。
所以统计位置不是数 length，而是要跳过代理对的第二单元——否则遍历索引会落在“半个 Emoji”上，导致 substring、slice 或光标定位错位。
如何用 codePointAt() 安全遍历字符串并记录真实字符位置
核心思路：用 for 循环配合 codePointAt()，每次检查当前索引是否为代理对的高位（0xD800 ），若是，则跳过下一个索引。
- 判断一个码点是否为代理对高位：
cp >= 0xD800 && cp - 若
str.codePointAt(i)返回值 ≥0x10000，说明该字符占两个 JS 字符位，下一次i应加 2 - 更稳妥的做法是：只要
str.charCodeAt(i)是高位代理（0xD800–0xDFFF），就直接i += 2
const str = "Hi ??! ??";
const positions = [];
for (let i = 0; i < str.length; ) {
const cp = str.codePointAt(i);
positions.push({ index: i, codePoint: cp, char: str[i] });
i += (cp > 0xFFFF) ? 2 : 1;
}
// positions[1].index === 3 → ?? 起始位置是 3，不是 2
// positions[2].index === 5 → ! 的位置正确，没被 Emoji 挤偏
常见踩坑：length 和 indexOf 不等于“字符数”，尤其在截取和搜索时
str.length 返回的是 UTF-16 编码单元数，不是 Unicode 字符数。例如 "??".length === 4（含两个代理对 + ZWJ 连接符），但 Array.from(str).length === 1。
- 用
str.substring(0, 3)截取前 3 个 UTF-16 单元，可能切在??中间，产生乱码或异常符号 -
str.indexOf("?")可能失败——因为单独的"?"是单个码点（0x1F680），但在"??"中它不作为独立字符存在，而是组合序列的一部分 - 正则匹配需加
u标志：/./u才能正确匹配一个 Unicode 字符，否则/./每次只匹配一个 UTF-16 单元
实际定位 Emoji 在字符串中的“视觉位置”要结合渲染上下文
即使你用 codePointAt() 算出了每个字符的真实起始索引，也不能直接等同于编辑器光标位置或 Canvas 文本绘制坐标——因为：
- 某些 Emoji（如家庭、职业组合）由多个码点 + ZWJ 连接符构成，浏览器/系统渲染为一个图形，但
codePointAt()仍按码点逐个返回 - 字体支持差异会导致同一串码点在不同设备上显示为 1 个或多个图形（例如旧 Android 可能拆开显示
??） - 富文本场景（如 contenteditable）中，用户点击位置需通过
getBoundingClientRect()+caretPositionFromPoint()获取，不能仅靠字符串索引推算
所以 codePointAt() 解决的是“JS 层字符边界对齐”问题，而不是“像素级光标定位”。真要做高精度光标映射，得走 TextMetrics 或 Web API（如 Intl.Segmenter）路线，那已是另一层复杂度了。
