应直接使用 strings.HasPrefix，因其是 O(1) 字节比对、不 panic、零内存分配、自动处理空字符串和超长前缀等边界情况，且天然支持 UTF-8（含中文、emoji），而正则匹配固定前缀性能差、开销大、易出错。
直接用 strings.HasPrefix，别用正则去匹配固定前缀——前者是 O(1) 字节比对，后者至少 O(n)，还带编译和状态机开销。
什么时候该用 strings.HasPrefix 而不是 regexp.MatchString
只要模式是静态、字面量、长度已知的前缀（比如 "GET "、"Content-Type:"、"v1/"），就无条件选 strings.HasPrefix。
- 它不 panic：自动处理空字符串、超长前缀等边界情况；手动切片
s[:len(p)] == p一错就崩 - 零分配：底层调用优化过的字节比较，不 new 任何对象，GC 友好
- 真正 O(1)：只比前缀长度个字节，和原字符串多长无关；正则哪怕写成
^GET\，也要先编译、再扫描、再回溯检查锚点 - UTF-8 安全：按字节比对，中文、emoji 前缀（如
"你好："）天然支持，无需额外处理
regexp.MustCompile 在前缀场景下为什么是性能陷阱
正则引擎不是为“开头几个字”这种简单任务设计的。哪怕你写了 ^https?:// 这种看似简单的模式，在高频调用中也会暴露三重开销：
- 每次
regexp.MustCompile都触发完整语法解析 + 状态机构建，CPU 密集，不可缓存 - 运行时要维护 NFA 状态栈，哪怕只匹配前 5 字节，也要走完锚点判断、字符类匹配、可选分支等流程
- 如果 pattern 是拼接出来的（比如
"^" + domain + "/api"），必须用regexp.Compile并检查err，否则线上静默失败
压测中常见现象：pprof 显示 regexp.(*Regexp).Compile 占 CPU 40%+，而实际匹配逻辑耗时不到 1%。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
前缀数量多时，strings.HasPrefix 链式调用也不行
比如路由匹配几十个前缀："/api/v1/"、"/admin/"、"/healthz"……这时逐个 strings.HasPrefix 是 O(k×m)，k 是前缀数，m 是平均前缀长度。
- 更优解是预建 map：把所有前缀转成
map[string]struct{}，然后取s[:minLen]（minLen 是最短前缀长度）查表，再精确比对 - 若前缀首字节差异大（如
"GET"、"POST"、"PUT"），可用switch s[0]分流，避免无效比对 - 别用正则
^(GET|POST|PUT)替代——它仍要构建分支状态机，且无法利用首字节索引
大小写与 Unicode 的真实影响
strings.HasPrefix 区分大小写，且不做 Unicode 归一化。这既是优点也是坑：
- 优点：行为确定、无隐藏转换、快。比如
strings.HasPrefix("HTTP/1.1", "http")→false，符合直觉 - 坑点：需要忽略大小写时，别写
strings.HasPrefix(strings.ToLower(s), strings.ToLower(p))——这会分配新字符串；改用strings.EqualFold(s[:len(p)], p)（前提是已确认len(s) >= len(p)） - 中文前缀没问题，但注意：它比的是 UTF-8 字节序列，不是 rune。所以
strings.HasPrefix(" Go语言", " Go")成立，但strings.HasPrefix("Go语言", "Go语")也成立——只要字节对得上，不管是不是“完整字符”
真正容易被忽略的是：前缀为空字符串时，strings.HasPrefix(s, "") 恒为 true。线上日志过滤规则因此漏掉全部数据的事故，已经发生过不止一次。
