必须预编译正则为包级变量，动态pattern用sync.Map缓存并检查err，避免.*回溯，高频匹配优先用FindStringSubmatchIndex零拷贝提取，仅判断存在时用MatchString更轻量。
直接在 Gin 的中间件或路由处理函数里调用 regexp.Compile 是性能黑洞，高频请求下 CPU 会陡增；必须预编译、缓存、避免 .*、优先用 FindStringSubmatchIndex 做零拷贝提取。
为什么不能在 Gin handler 里每次 regexp.Compile
Go 的 regexp.Compile 不是轻量字符串解析，它要构建 NFA、做状态机优化、甚至部分展开 DFA。每请求一次，就白跑一遍完整编译流程——实测 QPS 过千时，CPU 火焰图里 regexp.compile 占比超 30%。
- 错误写法：
re := regexp.MustCompile(`\d{3}-\d{4}`)写在GEThandler 里 → 每次请求都重编译 - 正确做法：包级变量提前编译，启动即 panic 暴露语法错误，无运行时 error 分支开销
- 动态 pattern（如用户传的手机号前缀）必须用
sync.Map缓存*regexp.Regexp，且必须检查err，否则nil指针调用直接 panic
FindStringSubmatchIndex 比 ReplaceAllString 更适合清洗场景
清洗常只需判断是否存在、提取位置、再切片取值，而非生成新字符串。ReplaceAllString 会为每个匹配分配新 string header 和底层数组，GC 压力随匹配数线性增长；而 FindStringSubmatchIndex 只返回 []int{start, end}，后续 input[idx[0]:idx[1]] 是零拷贝切片。
- 适用场景：HTTP header 解析、路径参数截取、日志行字段提取
- 关键约束：
input必须在整个生命周期内有效（不能是局部[]byte返回值），否则切片越界静默崩溃 - 只判断存在？用
re.MatchString(s)，比len(re.FindStringSubmatch([]byte(s))) > 0快 40%+
Gin 中过滤 HTML 标签的正则必须加 (?i) 并先解码
直接用 `]*>` 清洗会误杀 <3、漏掉 <img alt="Golang中使用Gin框架对特定正则表达式做过滤清洗" >、<!-- comment -->，甚至把 CDATA 或嵌套 script 里的合法 全干掉。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 必须前置调用
html.UnescapeString(s)，否则这类实体不会被识别为标签 - 正则应写成
(?i)]*>：忽略大小写 + 排除纯符号误匹配 - 收尾要做空格规整：
strings.TrimSpace+regexp.MustCompile(`\s+`).ReplaceAllString(" ", " ") - 若 regex 编译报
error parsing regexp: invalid UTF-8，不是正则写错，而是输入含非法 UTF-8 字节（比如 GBK 文件未转码），需先校验或强制转换
中文匹配别硬套 [\u4e00-\u9fa5]
这个范围漏掉扩展 A/B 区汉字、全角标点、“〇”、“〆”，也匹配不到日韩汉字兼容区字符。Gin 接口收到昵称或地址字段时，宽松识别中文必须扩大 Unicode 范围。
- 可用组合：
[\u4e00-\u9fff\u3400-\u4dbf\uf900-\ufaff\u3000-\u303f\uff00-\uffef] - 若需严格按 Unicode Han script 判断（如内容审核），
regexp不支持\p{Han}，得用unicode.Is(unicode.Scripts["Han"], r)逐 rune 扫描 - 性能权衡：正则粗筛 + unicode 细判，比纯 unicode 遍历快一个数量级，适合百万级文本预处理
最易被忽略的是 input 生命周期和编码一致性——Gin 默认读取 body 是 []byte，但很多清洗逻辑假设它是有效 UTF-8 字符串；一旦混入二进制或 GBK 数据，regexp 编译不报错，匹配却静默失效。
