使用反引号定义的原始字符串字面量可避免Go编译器解析转义，使正则中的\d等写法合法且直观，但需注意\b等仍需写成\\b以匹配正则语义，且不支持变量插值。
Raw String Literal里写正则为什么能少逃双反斜杠
因为 ` 包裹的字符串不解析转义， 就是字面量 ，不用写成 \。普通双引号字符串里，d 会被 Go 解析器当成非法转义（d 不是标准转义序列），直接报错 unknown escape sequence；而 `d+` 完全合法，正则引擎拿到的就是真正的 d+。
常见错误现象：
• 用 "d+" 编译正则 → error parsing regexp: invalid escape sequence: d
• 想绕开就写 "\d+" → 虽能过编译，但易漏写、难读，尤其嵌套多层时（比如匹配 Windows 路径 "C:\\Users\\.*"）
- 所有正则元字符（
.、*、?、、[、(等）在 raw string 中保持原义，无需额外转义 - 唯一需要处理的是反引号本身：如果正则里真要匹配
`字符，必须换方式——raw string 不支持转义反引号，所以得拆开拼接，比如`a` + "`" + `b` - 注意：raw string 里的换行会原样进入正则表达式，可能导致
^/$行锚点行为异常，必要时用
regexp.Compile 传 raw string 和普通 string 的实际区别
区别不在 regexp.Compile 本身，而在字符串字面量如何被 Go 编译器解释。传 `s+` 和 "\s+" 最终给到正则引擎的字节序列是一样的，但后者多了一层人工转义负担。
使用场景：
• 写路径匹配（`/api/vd+/users/w+`）
• 写 HTML 标签提取（`<div>]*>(.*?)</div>`，注意避免贪婪匹配陷阱）
• 写日志行解析（`d{4}-d{2}-d{2} d{2}:d{2}:d{2} [([^]]+)] (.*)`）
立即学习“go语言免费学习笔记（深入）”；
-
regexp.Compile接收string类型，它不管你是怎么写的，只看最终字节内容 - 但开发时用 raw string 能让代码和你脑中想的正则“长得一样”，减少心智负担
- 别在 raw string 里混用变量插值——Go 不支持，
`hello ${name}`是语法错误，得用fmt.Sprintf或字符串拼接
Raw string 里写正则容易忽略的边界情况
最常被跳过的不是语法，是语义：raw string 让你写得爽，但也掩盖了正则本身的歧义点。
常见错误现象：
• `word` 本意是单词边界，结果匹配失败 → 因为 在正则里是退格符（backspace）的 ASCII 控制字符，不是单词边界！正确写法是 `\bword\b`（哪怕在 raw string 里， 仍被正则引擎解释为退格）
• `[a-z]+` 在非 ASCII 文本里不匹配中文 → 这跟 raw string 无关，但开发者常误以为“写对了字符串就万事大吉”
- 正则中的
、B、A、Z等断言，必须写成\b、\B等 —— raw string 只管 Go 层转义，不管正则引擎内部规则 - Unicode 支持靠
p{L}这类，不是w，后者默认只含 ASCII 字母数字下划线 - 性能上无差异，但过度依赖 raw string 可能让团队新人误读正则逻辑，尤其当正则本身已很复杂时
什么时候不该用反引号写正则
当正则里需要动态拼接、或者含大量需运行时计算的片段时，硬塞进 raw string 反而更麻烦。
使用场景：
• 正则模板里要插入变量（如用户输入的 ID 前缀）→ 用 fmt.Sprintf 拼 `%sd+`
• 需要根据条件开关某些分组（如是否启用命名捕获）→ 直接构造字符串比维护多个 raw string 更可控
- raw string 是字面量，无法内嵌表达式，强行用
`prefix` + userPrefix + `d+`会破坏可读性 - 如果正则本身简单（如
"^[a-z]+$"），双引号反而更轻量，不必纠结 - CI/CD 流水线里做正则校验时，配置文件若用 YAML/JSON，就得用普通字符串格式，此时统一风格比炫技重要
真正卡住人的从来不是反引号怎么写，而是没想清正则要匹配什么、边界在哪、要不要 Unicode、有没有隐藏的换行或空格。写完 ` 包起来的正则，记得用 regexp.MatchString 多试几条真实样本，尤其边界 case。
