go中字符串相等判断应避免直接用==比较string指针，需解引用为s1 == *s2；截取子串前须检查utf-8字节越界，推荐用strings.splitn或[]rune；拼接大量字符串优先用strings.builder；strings.contains大小写敏感，忽略时应使用strings.indexfold或统一转小写。
字符串相等判断别用 == 比较指针
Go 里 string 是只读的底层字节数组 + 长度，值类型，直接用 == 是安全的——但很多人在结构体字段或 map key 里误传了 *string，结果比较的是指针地址。
- 常见错误现象：
if s1 == s2返回 false，但打印内容完全一样；查出来其实是s1和s2都是*string类型 - 正确做法：先解引用再比，
*s1 == *s2；或者统一用string类型传参，避免裸指针 - 性能影响：解引用开销极小，但滥用
*string会干扰逃逸分析，导致本可栈分配的字符串上堆
截取子串前务必检查索引越界
Go 字符串底层是字节数组，s[i:j] 的 i、j 是字节偏移，不是 rune 个数。中文、emoji 等多字节字符极易触发 panic: runtime error: slice bounds out of range。
- 使用场景：日志截断、URL 路径解析、用户昵称前 10 个字符显示
- 安全做法：用
utf8.RuneCountInString(s)得到 rune 数，再转成字节位置；或直接用strings.SplitN(s, "", n+1)拆 rune 切片 - 参数差异：
s[0:10]可能切在 UTF-8 中间字节，而[]rune(s)[0:10]是真正“前 10 个字符”，但会额外分配内存
拼接大量字符串优先用 strings.Builder
频繁用 + 或 fmt.Sprintf 拼接，每次都会产生新字符串，旧的被 GC，小量没问题，循环几百次以上性能明显下滑。
- 常见错误现象：服务压测时 CPU 飙高，pprof 显示大量时间花在
runtime.makeslice和垃圾回收 - 实操建议：初始化
var b strings.Builder，用b.WriteString()或b.WriteRune()；最后b.String()获取结果 - 兼容性注意：Go 1.10+ 才有
strings.Builder；低于此版本可用bytes.Buffer替代（但语义稍重）
strings.Contains 对大小写敏感，别默认当成模糊匹配
strings.Contains 完全区分大小写，strings.Contains("Hello", "hello") 返回 false。很多人以为它类似 SQL 的 LIKE，结果线上逻辑漏判。
- 使用场景：权限校验（如检查 path 是否含
/admin）、关键词过滤、配置项开关识别 - 正确做法：需要忽略大小写时，先统一转小写再查，
strings.Contains(strings.ToLower(s), strings.ToLower(substr)) - 性能提示：如果
s很长且substr很短，建议用strings.IndexFold（Go 1.19+），它内部优化了大小写折叠逻辑，不强制全量转换
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
