Go字符串是只读struct{data *byte, len int}，传值不拷贝底层数组；修改需先转[]byte再拷贝，len返回字节数非rune数，遍历用for range，拼接多用strings.Builder。
Go 字符串底层是只读的 struct，不是指针
很多人以为 string 是类似 C 的字符数组指针，其实 Go 的 string 是一个两字段的只读结构体：struct{ data *byte; len int }。它本身很小（16 字节），可直接传值，但 data 指向的底层字节数组不可修改。
这意味着：对 string 变量赋值、传参、返回，都是复制这个 struct，不拷贝底层数组；但一旦你试图通过 unsafe 或反射去改 data 指向的内容，就踩到 Go 的内存安全红线——运行时可能 panic，或者在 GC 优化下行为不可预测。
- 不要用
unsafe.String或reflect.StringHeader去“伪造”字符串，除非你完全控制内存生命周期（比如写 cgo 包装器） -
string和[]byte转换开销极小（只是重解释 header），但转换后得到的[]byte若被修改，原string不会变——它们共享底层数组，但string的只读性由语言保证，不是靠内存保护 - 编译器可能把短字符串字面量放进只读段，尝试修改会触发 SIGSEGV（尤其在 CGO 或 mmap 场景下）
为什么 string 不能直接转成 []byte 再改内容
因为 Go 禁止通过任何合法方式修改 string 底层数组。看似简单的 []byte(s) 转换，生成的是一个新切片，指向同一块内存；但只要你对这个切片做写操作，就破坏了 string 的不变性契约。
常见错误现象：panic: runtime error: cannot assign to string value 不会出现（那是语法错误），但实际运行中可能触发 GC 异常、数据竞争检测失败，或在某些版本中静默失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：需要修改时，先用
[]byte(s)拷贝一份，改完再转回string(b)—— 这次是真正的内存拷贝 - 性能注意：频繁转换 + 修改字符串（如拼接、替换）应优先用
strings.Builder，避免反复分配 - 兼容性坑：Go 1.20+ 对只读内存段更严格，某些旧的
unsafe黑科技在新版本里直接 crash
len(s) 返回字节数，不是 rune 数
len(s) 总是返回底层字节数，不是 Unicode 字符（rune）个数。这是最常被误用的地方，尤其处理中文、emoji 时。
例如 s := "??"（一个程序员 emoji），len(s) 是 4（UTF-8 编码占 4 字节），但 utf8.RuneCountInString(s) 才是 1。
- 遍历字符串用
for range s，它按 rune 拆分，每次迭代给的索引是字节偏移，值是 rune - 取子串
s[i:j]必须确保i和j是合法字节边界，否则 panic：panic: runtime error: slice bounds out of range - 想安全截断前 N 个字符？别用
s[:N]，要用string([]rune(s)[:N])（注意内存开销）或strings.Cut/utf8.DecodeRuneInString手动解析
字符串拼接：什么时候用 +，什么时候用 strings.Builder
+ 在编译期已知的字面量拼接（如 "hello" + "world"）会被编译器优化为单个字符串；但运行时拼接（尤其是循环中）会产生大量中间对象，GC 压力陡增。
典型错误场景：日志拼接、HTTP 响应体构建、模板渲染中用 += 累加字符串。
- 2~3 次固定拼接，用
+更清晰，性能差异可忽略 - 循环内拼接、或拼接次数不确定，必须用
strings.Builder：它内部用切片扩容，避免重复分配 - 注意
Builder.String()返回的是新字符串，不会复用内部 buffer；如果后续还要追加，别反复调用String()，直接继续WriteString - Go 1.22+ 新增
strings.Join对小切片做了优化，但对动态增长仍不适用
len 就是字符数」——这两个假设错一次，调试半小时。 
