go字符串底层是struct{data *byte; len int}的只读结构体，无容量和锁；拼接时需全量复制并新分配内存，导致高频操作下gc压力增大。
Go 字符串底层到底存了什么
Go 的 string 不是字符数组，也不是指针，而是一个只读的、两字段结构体：struct{ data *byte; len int }。它不包含容量（cap），也不带 header 或锁，所以创建和传递极轻量——但正因如此，任何修改都会触发新分配。
为什么 string 拼接一多就变慢
每次用 + 或 fmt.Sprintf 拼接，Go 都要 malloc 一块新内存，把旧内容 memcpy 过去。不是“在原地追加”，而是“全量复制”。高频拼接（比如日志组装、模板渲染）下，GC 压力和内存抖动会明显上升。
- 小量拼接（+ 最简洁，编译器还能做一定优化
- 循环内拼接或不确定次数：必须用
strings.Builder，它的Grow和内部buf能复用底层数组 - 已知最终长度：初始化
strings.Builder时传入预估大小，避免多次扩容
string 和 []byte 转换为什么不是零成本
string 和 []byte 之间转换看似只是类型别名，实际会触发一次底层数据拷贝（除非使用 unsafe 强转）。这是因为 Go 要保证 string 的只读语义——如果允许共享同一块可写内存，就可能通过 []byte 修改 string 内容，破坏字符串常量池和并发安全。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 读多写少场景（如解析 JSON、HTTP header）：先转成
[]byte处理，最后再转回string（仅一次拷贝） - 需要频繁修改内容：直接用
[]byte，处理完再转，避免反复转换 - 绝对不要在生产代码里用
unsafe.String/unsafe.Slice绕过拷贝，除非你完全掌控内存生命周期且已压测验证
中文乱码？其实是 rune 和 byte 的混淆
Go 的 string 是 UTF-8 编码的字节序列，len(s) 返回的是字节数，不是字符数。一个中文字符占 3 个字节，所以 len("你好") == 6；但 len([]rune(s)) == 2。很多 bug 来自直接拿 len 当“字符长度”用，或者用 s[i] 取单个“字符”（实际取的是字节）。
- 遍历字符：用
for _, r := range s，r是rune - 截取前 N 个字符：先转
[]rune，切片后再转回string（注意性能代价） - 正则、JSON 解析等标准库操作都默认按 UTF-8 处理，无需手动转
rune，除非你要做字形/Unicode 层面的判断
最常被忽略的一点：字符串字面量在源码里是 UTF-8，但如果你从文件、网络或 C API 读入二进制数据，它未必是合法 UTF-8——这时 range 会跳过非法字节，utf8.RuneCountInString 会返回 -1，得先用 utf8.Valid 校验。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
