go 的 regexp 包轻量高效但不支持后行断言等高级特性，需预编译正则提升性能，推荐用 mustcompile 处理固定模式、compile 处理动态模式，submatch 方法用于提取分组，多行匹配需显式加 (?m)，应避免嵌套量词并辅以单元测试。
Go 的 regexp 包足够轻量且高效，但默认不支持后行断言、原子组等高级特性，匹配逻辑也和 JavaScript 或 Python 有细微差别——比如 FindString 只返回第一个匹配，而 FindAllString 才返回全部。
用 regexp.Compile 预编译正则以提升性能
频繁使用的正则表达式必须预编译，否则每次调用 regexp.MustCompile 或 regexp.Compile 都会重新解析，开销明显。尤其在 HTTP handler 或循环中，未编译会导致 CPU 毛刺。
-
regexp.MustCompile在编译失败时 panic，适合写死的、确定合法的正则（如`^\d{3}-\d{2}-\d{4}$`） -
regexp.Compile返回(*Regexp, error)，适合运行时拼接的 pattern（如用户输入的搜索关键词），需手动检查 error - 编译后的
*regexp.Regexp是线程安全的，可全局复用
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
func isValidEmail(s string) bool {
return emailRegex.MatchString(s)
}
FindStringSubmatch 和 FindStringSubmatchIndex 的区别与选型
当你需要提取分组内容（比如 URL 中的协议、域名、路径），别只用 FindString——它只返回整个匹配串。真正有用的是带 Submatch 的系列方法，它们能按括号分组返回子匹配。
-
FindStringSubmatch返回[]string，每个元素是某一分组的字符串值（含第 0 组，即完整匹配） -
FindStringSubmatchIndex返回[][]int，每项是[start, end]索引对，适合原字符串太长、不想拷贝子串时使用 - 如果正则里没写括号（
()），那Submatch类方法只会返回一个元素（完整匹配），和FindString效果一致
re := regexp.MustCompile(`(https?)://([^/]+)(/.*)?`)
match := re.FindStringSubmatch([]byte("https://golang.org/pkg/regexp/"))
// match == []string{"https://golang.org/pkg/regexp/", "https", "golang.org", "/pkg/regexp/"}
注意 ^ 和 $ 在多行模式下的行为
Go 的 regexp 默认不开启多行模式（m 标志），所以 ^ 只匹配整个输入开头，$ 只匹配结尾。若想让它们匹配每行起止，必须显式加 (?m) 前缀：
立即学习“go语言免费学习笔记（深入）”；
-
^(?m)error:→ 匹配每行开头的error: -
(?m)^error:.*$→ 匹配整行以error:开头的内容 - 没有
(?m)时，^和$在含换行符的字符串中几乎失效，容易误判为空匹配 -
\A和\z始终锚定整个输入首尾，不受(?m)影响，可替代默认行为
避免正则回溯爆炸：慎用嵌套量词和模糊匹配
Go 的正则引擎基于 RE2，不支持回溯，因此不会出现 catastrophic backtracking，但某些写法仍会显著变慢或匹配失败——比如 .* 后紧跟必须满足的条件（.*abc 在超长文本末尾才含 abc 时，会扫描整段）。
- 优先用非贪婪
.*?替代.*，但注意 Go 不支持.*?的非贪婪语法（它统一按最左最长匹配），实际应改用否定字符类，例如[^x]*x替代.*?x - 避免
(a+)+、(ab*)*这类嵌套重复结构，RE2 会拒绝编译并报错invalid or unsupported Perl syntax - 对日志解析等场景，先用
strings.Index快速定位大致位置，再对局部子串用正则，比全量扫描更稳
真正难的不是写出能跑的正则，而是预判它在边界输入下的行为——比如空字符串、超长字段、Unicode 组合符、嵌套 HTML 标签。建议所有正则都配上最小/最大长度、典型异常 case 的单元测试。
