String.raw是JavaScript内置的静态标签函数，用于模板字符串中跳过反斜杠转义，保留字面值（如 、 等均不被解析）；它仅对反引号包裹的模板字符串生效，且支持插值，但仅静态片段保持raw，插值内容仍按常规处理。
String.raw 是什么，它和普通字符串字面量有什么区别
String.raw 是一个内置的模板字符串标签函数，它的作用是跳过所有反斜杠转义处理——包括
、 、u{...}、x，甚至 \ 本身也只被当作两个字符，而不是转义序列。这和直接写 `
`（换行符）或 "\n"（需要双写反斜杠）完全不同。
它只对**模板字符串（用反引号包裹）生效**，不能用于普通单/双引号字符串；而且必须作为标签函数调用，即写成 String.raw`...`，不能写成 String.raw("...")。
为什么不能直接用双反斜杠代替 String.raw
手动写 "C:\Users\name\file.txt" 确实能避免解析错误，但可读性差、易出错，尤其在正则、路径、SQL 或 JSON Schema 等含大量反斜杠的场景里。更关键的是：某些转义在普通字符串中根本无法表示，比如 （空字符）在非 raw 模板中会被解释为 u0000，而 String.raw` ` 就是真正的两个字符： 和 0。
- 正则表达式字面量里写
/d+.?d*/很自然，但若拼接进字符串，就得写"\d+\.?\d*"——String.raw`d+.?d*`更接近原意 - Windows 路径
String.raw`C: emp ew ile.txt`输出就是字面的C: emp ew ile.txt，不会把 -
String.raw`u{1F600}`不会变成 ?，而是保留u{1F600}这 7 个字符，适合生成待后续解析的 Unicode 字符串模板
String.raw 的参数行为和常见误用
String.raw 实际接收两个参数：一个是描述模板结构的 strings 数组（含原始未转义的静态片段），另一个是插值表达式的值数组。这意味着它支持插值，但插进去的内容**不经过 raw 处理**——只有反引号内的静态部分跳过转义。
例如：
const name = "Alice";
console.log(String.raw`Hello
${name} !`); // 输出：Hello
Alice !
注意：
和 是原始字符串里的字面量，没被解析；但 ${name} 插入的是普通字符串 "Alice"，不是 raw 的。
- 别写
String.raw("...")—— 这会报错，因为String.raw不接受普通字符串参数 - 别依赖
String.raw来“修复”已转义过的字符串，比如从JSON.parse或input.value读来的内容，它只作用于字面量定义阶段 - Node.js 早期版本（u 和
x的 raw 行为有兼容性差异，建议在目标环境中实测String.raw`u0041A`是否输出u0041A而非AA
什么时候该用 String.raw，什么时候不该用
适合用 String.raw 的典型场景：正则模式字面量、文件系统路径、CSS-in-JS 片段、需要保留反斜杠的协议字符串（如 LDAP DN）、生成代码的代码（metaprogramming）。
不适合的场景：普通用户输入、HTTP 响应体、JSON 数据、HTML 内容——这些本就不该靠字符串字面量硬编码，更不该用 String.raw 去“假装”原始内容。
- 正则推荐写法：
const re = new RegExp(String.raw`^d{3}-d{2}-d{4}$`)，比new RegExp("^\d{3}-\d{2}-\d{4}$")清晰 - 路径拼接慎用：
String.raw`/usr/local/bin/` + cmd是错的，因为拼接后cmd仍可能含非法字符；应优先用path.join()或URL构造器 - 如果只是想让 console 输出带反斜杠的字符串用于调试，
JSON.stringify(str)往往比String.raw更可靠，因为它明确控制转义逻辑
真正容易被忽略的是：它不解决运行时字符串的转义问题，只解决“你写代码那一刻”的字面量解析。一旦字符串进入变量、经过网络传输或存储再读回，String.raw 就完全不起作用了。
