regexp包是go中用于精确、高效、可复用模式操作的工具，补足strings等包无法处理的结构识别场景，如邮箱验证、时间戳提取、html标签替换；应根据正则来源选择compile（运行时动态）或mustcompile（硬编码预编译），避免循环中重复编译，并注意默认.不匹配换行符需用(?s)修正。
regexp 包不是“文本处理语言”的替代品，它是 Go 中用于**精确、高效、可复用的模式操作**的工具。它不取代字符串切片、strings 或 bufio，而是补足它们无法优雅解决的场景：比如提取嵌套结构、验证复杂格式、跨行定位、动态替换。
为什么不能直接用 strings.Contains 代替 regexp.MatchString
因为语义不同：strings.Contains 只能判断子串是否存在，而 regexp.MatchString 判断的是「是否符合某种抽象规则」。
- 想确认输入是合法邮箱？
strings.Contains("a@b", "@")会放行"@@"、"x@y@z"、"@.com"—— 这些都不是邮箱 - 想提取日志中所有带毫秒精度的时间戳（如
2024-03-15T14:22:33.123Z）？strings.Index无法识别时间格式边界，容易截断或错位 - 想把 HTML 片段里所有
<a href="...">...</a>标签替换成 Markdown 链接？手写字符串扫描极易漏掉属性顺序、引号类型、嵌套标签等变体
这些都不是“找子串”问题，而是“识别结构”问题 —— 正则表达式就是为此设计的。
regexp.Compile 和 regexp.MustCompile 怎么选
关键看错误能否在运行时容忍：
- 模式来自配置文件、用户输入、数据库字段 → 必须用
regexp.Compile，并检查err；否则非法正则会 panic，直接 crash 服务 - 模式是硬编码的常量（如
`\d{4}-\d{2}-\d{2}`），且经测试验证无误 → 用regexp.MustCompile更简洁，编译失败即暴露问题 - 注意：即使硬编码，也建议提前声明为包级变量，避免每次调用都重复编译
错误示例：re := regexp.MustCompile(`[a-z+`) // 缺少右括号，panic
多行文本匹配失败，90% 是因为 . 不匹配换行符
Go 的 regexp 默认使用 POSIX 行模式：. 匹配除 \n 外的任意字符。这意味着：
-
re := regexp.MustCompile(`start.*end`)在"start\nmiddle\nend"上永远返回空 - 修复方法只有两种可靠方案：
– 加(?s)前缀：`(?s)start.*end`（推荐，语义明确）
– 改用字符类：`start[\s\S]*end`（兼容性略好，但可读性差） -
(?m)是另一回事：它让^和$匹配每行首尾，不是解决.问题的
性能陷阱：别在循环里反复调用 regexp.MatchString
这个函数内部每次都会隐式调用 regexp.Compile，开销远高于预编译对象的 MatchString 方法：
- 高频场景（如 HTTP 请求体校验、日志行过滤）必须预编译：
var emailRe = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`) - 如果正则模式本身是动态拼接的（如基于用户输入构造），优先考虑是否真需要正则——有时
strings.HasPrefix+strings.HasSuffix+strings.Count组合更安全、更快 - RE2 引擎虽保证线性时间，但「线性」是相对于文本长度而言；模式越复杂（尤其含嵌套量词），常数因子越大
真正容易被忽略的点是：正则不是银弹。当你要解析 JSON、XML、URL 或日期，优先用 encoding/json、net/url、time.Parse —— 它们更准确、更安全、更容易调试。正则只该用在「模式模糊但结构可描述」的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
