javascript字符串用utf-16编码，超bmp字符以代理对表示；默认正则按代码单元匹配，会错误拆分代理对；加u标志后按unicode码点匹配，配合for...of、array.from等api可正确处理emoji等字符。
JavaScript 字符串内部使用 UTF-16 编码，这意味着一个 Unicode 码点（如 emoji 或某些中文字符）若超出 BMP（Basic Multilingual Plane，U+0000–U+FFFF），就会被表示为一对 16 位的 代理对（Surrogate Pair）：一个高位代理（High Surrogate，U+D800–U+DBFF）加一个低位代理（Low Surrogate，U+DC00–U+DFFF）。正则表达式在默认模式下按 UTF-16 代码单元（code unit）匹配，而非按 Unicode 码点，因此会把代理对拆成两个独立“字符”处理——这是很多正则行为异常的根源。
默认正则会错误切分代理对
例如：'??'.length === 2（实际是 4 个 UTF-16 单元：0xD83D 0xDC68 0x200D 0xD83D 0xDCBB，含多个代理对），而 /./g.exec('??') 可能只匹配到前半部分（如 0xD83D），导致乱码或不完整捕获。
- 普通正则（无
u标志）将字符串视为 16 位单元序列，不识别代理对逻辑 -
/./匹配一个代码单元，不是“一个用户感知的字符” -
.length、String.prototype.charAt()、for...of（例外：它按码点迭代）等行为均受此影响
启用 u 标志：让正则按 Unicode 码点工作
添加 u 标志后，正则引擎将整个字符串视为 Unicode 码点序列，自动识别并保护代理对完整性：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
/./u能正确匹配一个 emoji（如??）为单个元素 -
/\p{Emoji}/u可用 Unicode 属性类精准匹配 emoji -
/[\u{1F468}\u{200D}]/u中的\u{...}写法支持 Unicode 码点字面量（需u） - 量词（如
+、{2}）和字符类（如[a-z]）也基于码点语义执行
避免手动操作代理对：优先用现代 API
不要用 charCodeAt() + 手动判断高低代理来拼接码点；改用更安全的原生方法：
-
for (const ch of str) { ... }—— 自动按码点迭代，ch是完整字符 -
Array.from(str)—— 将字符串转为码点数组（每个元素是完整字符） -
str.codePointAt(i)—— 返回位置i开始的码点值（可 > 0xFFFF） -
String.fromCodePoint(0x1F468)—— 安全生成任意码点字符（包括代理对）
注意 split、replace 等方法的隐式正则行为
这些方法若传入字符串（如 str.split(' ')），不涉及正则，按 UTF-16 单元处理；但若传入正则（如 str.split(/ /)），则是否带 u 标志决定语义：
-
'?? a'.split(/./)→["", "", "", "", "", " a"]（错切代理对） -
'?? a'.split(/./u)→["", " ", "a"]（正确，三个码点） -
str.replace(/./g, 'X')不带u会把一个 emoji 替换为两个X；加u才是每个字符一个X
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
