String.prototype.codePointAt 是统计 Emoji 语义长度的必要选择，因其按 Unicode 码点而非 UTF-16 码元计数，能正确识别增补平面字符；但不解析 ZWJ 序列，仅逐个返回组成码点。
为什么 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 < str.length; i++) {
const cp = str.codePointAt(i);
count++;
if (cp > 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。
- 务必先做
typeof str === 'string'检查 - 索引越界时
codePointAt返回undefined，别直接参与数值运算 - 不要混淆
codePointAt和charCodeAt：后者永远只返回 16 位值，对代理对只能取到高位或低位，无法还原真实码点
真正难的是组合型 Emoji 和区域指示符（如 ??），它们由多个独立码点组成，codePointAt 只能帮你数清楚“有几个码点”，而不是“有几个脸”。
