regexp.Compile失败因忽略error返回nil，后续调用panic；FindStringSubmatch找首个匹配并返回[]byte，FindAllStringSubmatch找全部并返回[][]byte；Go中\d仅匹配0-9，不支持Unicode数字；拼接用户输入需用QuoteMeta转义。
为什么 regexp.Compile 失败但没报错？
Go 的 regexp.Compile 返回 (*Regexp, error)，但很多人只取第一个返回值，忽略 error，导致 panic 或静默失败。它不抛异常，出错就返回 nil + error，后续调用 nil 的 *Regexp 会直接 panic。
- 必须检查
err != nil，哪怕只是log.Fatal(err) - 调试时可打印
err.Error()，常见错误如error parsing regexp: missing closing )、invalid escape sequence - 线上环境建议用
regexp.MustCompile（编译失败直接 panic），适合硬编码的固定正则，开发阶段更容易暴露问题
FindStringSubmatch 和 FindAllStringSubmatch 区别在哪？
前者只找第一个匹配，后者找全部；但更关键的是返回值类型不同：FindStringSubmatch 返回 []byte，而 FindAllStringSubmatch 返回 [][]byte —— 容易误当单层切片遍历，结果越界或逻辑错乱。
- 如果正则带子表达式（括号），
FindStringSubmatch返回整个匹配 + 所有子匹配组成的扁平[]byte；要用FindStringSubmatchIndex配合原字符串切分才安全 -
FindAllStringSubmatch对每个完整匹配返回一个[]byte，但不会自动拆子组；需要搭配FindAllStringSubmatchIndex才能精准提取捕获组内容 - 性能上，
FindAll*系列会分配更多内存，高频调用场景建议复用*Regexp实例，并考虑用FindAllSubmatch（接收[]byte输入）避免 string/[]byte 转换开销
为什么 \d 在 Go 正则里不匹配中文数字？
Go 的 regexp 包默认使用 RE2 引擎，不支持 Unicode 类别（如 \p{Nd}），\d 仅等价于 [0-9]，和 Python/JavaScript 行为不同。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 要匹配所有 Unicode 数字字符（含中文数字、阿拉伯数字等），显式写成
[0-9\u4e00-\u9fa5]不可靠 —— 中文数字只有“零一二三四五六七八九十百千万亿”，不是连续码位；正确做法是用[\p{N}&&\p{Han}]？不行，RE2 不支持&&交集语法 - 实际方案：先用
unicode.IsNumber做后处理，或改用第三方库如github.com/dlclark/regexp2（支持 .NET 风格正则，含完整 Unicode 类） - 若只需 ASCII 数字，保持
\d即可，但需在文档或注释里明确标注“仅限阿拉伯数字”，避免被后续维护者误用
如何安全地拼接用户输入到正则中？
直接用 fmt.Sprintf(`%s.*%s`, userA, userB) 构造正则极易被注入 —— 用户输个 .* 或 $ 就破坏语义，甚至引发回溯爆炸。
立即学习“go语言免费学习笔记（深入）”；
- 必须对用户输入调用
regexp.QuoteMeta，它会把所有正则元字符转义为字面量，例如QuoteMeta(`a.b+c$`)→`a\.b\+c\$` - 注意
QuoteMeta不处理空字符串或非字符串类型，传入前确保是string且非 nil - 如果用户输入用于锚定位置（如开头/结尾匹配），还要额外补上
^/$，但得确认是否真需要严格锚定 —— 很多场景其实该用strings.Contains或strings.HasPrefix更快更安全
正则最难的从来不是写法，而是边界：哪些该交给正则，哪些该拆出去用字符串函数或 Unicode 工具处理。尤其在 Go 里，regexp 包的保守设计意味着你得主动补足语义，而不是依赖“高级特性”兜底。
