如何用 String.prototype.codePointAt 处理包含表情符号（Emoji）的高位字符长度统计-js教程-PHP中文网

string.prototype.codepointat 是统计 emoji 语义长度的必要选择，因其按 unicode 码点而非 utf-16 码元计数，能正确识别增补平面字符；但不解析 zwj 序列，仅逐个返回组成码点。

如何用 string.prototype.codepointat 处理包含表情符号（emoji）的高位字符长度统计

为什么 `String.prototype.codePointAt` 是统计 Emoji 长度的必要选择

JavaScript 中的 length 属性会把一个 Emoji（如 "?‍?"）算作 2 或更多单位，因为它按 UTF-16 码元计数，而多数 Emoji 占用两个代理对（surrogate pair）。但真实语义长度应为 1 —— 这正是 codePointAt 要解决的问题：它返回 Unicode 码点（code point），能正确识别从 U+0000 到 U+10FFFF 的完整字符，包括增补平面（Supplementary Plane）上的 Emoji。

如何用 `codePointAt` 遍历并统计真正字符数

不能直接用 for (let i = 0; i 然后对每个 <code>i 调用 codePointAt(i)，因为这会重复计数代理对的高位和低位。必须跳过低位代理（U+DC00–U+DFFF）。

检查 str.codePointAt(i) 返回值，若在 0x10000 以上，说明该位置是高位代理，对应一个完整 Emoji，此时应 i += 2
若返回值在 0xD800–0xDFFF 范围内，说明这是孤立的代理码元（非法或截断字符串），可视为 1 个“损坏字符”处理
正常 BMP 字符（ 或 <code>> 0xDFFF）则 i += 1

简明实现：

function countCodePoints(str) {
  let count = 0;
  for (let i = 0; i  0xFFFF) i++; // 跳过后续低位代理
  }
  return count;
}

`codePointAt` 和 `Array.from`、`for...of` 的行为差异

Array.from(str) 和 for (const ch of str) 内部已基于 Unicode 码点迭代，天然支持 Emoji，结果与手动用 codePointAt 跳步一致。但它们会生成新数组或执行额外循环，有内存/性能开销；而 codePointAt 是零分配的纯计算方式，适合高频、长文本或内存敏感场景。

Array.from("?‍❤️‍?‍?").length → 1（正确）
"?‍❤️‍?‍?".length → 25（完全不可信）
"?‍❤️‍?‍?".codePointAt(0) → 129485（即 0x1F9CD，Zwj 序列起始码点）

注意：codePointAt 不解析 ZWJ（零宽连接符）序列，它只保证单个码点或代理对的提取；像 "?‍?" 这类组合 Emoji 在 JS 中实际由多个码点（含 ZWJ）构成，codePointAt 仍会逐个返回它们——所以“语义字符数”和“视觉字形数”仍是两回事。

容易被忽略的边界情况和兼容性提醒

codePointAt 在 IE 中完全不支持，Node.js 从 v4+ 开始支持，现代浏览器均无问题。但更隐蔽的问题是：空字符串、null、undefined 传入会报错，需提前 guard；另外，codePointAt(-1) 或超出索引会返回 undefined，不是 NaN。