Go中判断字符串前缀应使用strings.HasPrefix，时间复杂度O(1)，需导入"strings"包、注意空字符串返回true、区分大小写、不支持正则；字节切片则用bytes.HasPrefix。
Go 里没有叫 Prefix 的函数，别被名字带偏——你要的大概率是 strings.HasPrefix 或 bytes.HasPrefix。
strings.HasPrefix 是字符串前缀匹配的唯一标准方式
Go 标准库不提供名为 Prefix 的通用函数，所有「判断是否以某串开头」的场景，都该用 strings.HasPrefix。它快（O(1) 字节比对）、安全（不 panic）、无需手动切片。
- 必须显式
import "strings"，不能直接"hello".HasPrefix(...) - 调用顺序是
strings.HasPrefix(s, prefix)，不是prefix.HasPrefix(s) - 传空字符串
""当prefix时返回true，但业务逻辑中通常要提前拦截：prefix != "" && strings.HasPrefix(s, prefix) -
prefix比s长？自动返回false，不用自己len判断 - 区分大小写：
strings.HasPrefix("APIv2", "apiv2")→false
bytes.HasPrefix 用于 []byte 场景，行为一致但类型不同
当你处理的是原始字节（比如 HTTP body、文件读取、网络包），别转成 string 再调 strings.HasPrefix——浪费内存且可能破坏 UTF-8 安全性。直接上 bytes.HasPrefix。
- 签名是
bytes.HasPrefix(s []byte, prefix []byte) bool - 和
strings.HasPrefix逻辑完全一致，只是输入类型为切片 - 若已有
string又必须用bytes版本，用[]byte(myStr)转换即可，无拷贝开销（Go 1.22+ 对 string→[]byte 转换做了优化） - 错误示范：
bytes.HasPrefix([]byte("hello"), "hel")—— 第二个参数类型错，编译不过
别把前缀匹配和前缀和、Trie、KMP 混在一起
名字带“前缀”不等于功能相关。实际编码中容易因命名相似踩坑：
-
strings.HasPrefix≠ 前缀和（prefixSum数组）：后者是数值累加，用于区间求和，和字符串无关 -
strings.HasPrefix≠ Trie 的StartsWith：Trie 支持动态词库、模糊匹配、自动补全，而HasPrefix就是纯静态字面量比对 -
strings.HasPrefix≠ KMP 的next数组：后者是模式串自身 border 长度，用于子串搜索加速，不暴露给日常使用 - 想支持通配符或正则？
strings.HasPrefix不干这事——换regexp.MatchString，但注意性能代价
真正难的不是调用函数，而是想清楚你要匹配的是字面值、路径语义、还是用户感知的“前缀”。比如 HasSuffix("/home/user/", "/") 返回 true，但它不代表这是目录——那是 filepath.Base 或 strings.TrimSuffix 的事。匹配逻辑一旦脱离原始字节含义，就得加清洗或换语义模型。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
