拆开 Go 字符串：16 字节背后的设计哲学
我们每天都在写 s := "hello"，但这个 s 到底是什么？它不是字符数组，不是对象，也不是指针——它只是一个 16 字节的"说明书"。今天把这层窗户纸捅破。
字符串的真身：一个两字段结构体
Go 运行时的字符串定义精简到极致：
// runtime/string.go 的等价定义
type stringStruct struct {
str unsafe.Pointer // 指向底层只读字节数组
len int // 字节数（注意：不是字符数）
}
64 位平台上指针 8 字节 + int 8 字节，合计 16 字节。不信？直接量给你看：
package main
import (
"fmt"
"strings"
"unsafe"
)
// stringHeader 镜像 runtime 中的字符串头结构, 仅用于观察内存布局
type stringHeader struct {
Data unsafe.Pointer
Len int
}
func main() {
// 1. 一个 string 在内存中只是 16 字节: {Data 指针, Len 字节数}
s := "hello, gopher"
fmt.Printf("1. unsafe.Sizeof(string) = %d bytes\n", unsafe.Sizeof(s))
header := (*stringHeader)(unsafe.Pointer(&s))
fmt.Printf(" Data = %p, Len = %d, first byte = %c\n",
header.Data, header.Len, *(*byte)(header.Data))
// 2. 子串切片零拷贝, 与母串共享底层数组
sub := s[0:5]
subHeader := (*stringHeader)(unsafe.Pointer(&sub))
fmt.Printf("2. sub = %q, 与母串共享底层数据: %v\n", sub, subHeader.Data == header.Data)
// 3. len 数字节不数字符: 中文 UTF-8 每字 3 字节
cn := "你好"
fmt.Printf("3. len(%q) = %d 字节, []rune 后 = %d 字符\n", cn, len(cn), len([]rune(cn)))
// 4. string -> []byte 常规转换会拷贝, 修改互不影响
b := []byte(s)
b[0] = 'H'
fmt.Printf("4. 拷贝转换后修改: s = %q, b = %q\n", s, b)
// 零拷贝只读视图 (Go 1.20+)
raw := []byte("zero-copy view")
view := unsafe.String(&raw[0], len(raw))
fmt.Printf(" 零拷贝 view = %q\n", view)
// 5. 循环拼接用 strings.Builder, 预分配容量避免反复扩容
var sb strings.Builder
sb.Grow(64)
for i := 0; i < 5; i++ {
fmt.Fprintf(&sb, "part%d;", i)
}
fmt.Printf("5. Builder 拼接: %q\n", sb.String())
// 6. 字符串比较是值语义, 按内容逐字节比较
fmt.Printf("6. \"abc\" == \"abc\": %v\n", "abc" == "abc")
}
运行输出：
1. unsafe.Sizeof(string) = 16 bytes
Data = 0x4aa2832, Len = 13, first byte = h
2. sub = "hello", 与母串共享底层数据: true
3. len("你好") = 6 字节, []rune 后 = 2 字符
4. 拷贝转换后修改: s = "hello, gopher", b = "Hello, gopher"
零拷贝 view = "zero-copy view"
5. Builder 拼接: "part0;part1;part2;part3;part4;"
6. "abc" == "abc": true
16 字节结构带来的三个推论
理解了这个结构，很多"理所当然"就有了解释。
传参极廉价。 字符串作为函数参数传递时，复制的只是这 16 字节的头，底层字节数组被共享。传一个 1GB 的字符串和传一个空字符串，成本完全一样。
比较按内容。 == 先比长度再逐字节比内容，是比"值"而不是比"地址"。这和 C 的 char* 比较指针、Java 要用 equals 都不同，Go 在这点上直觉友好。
子串零拷贝。 上面输出第 2 行证实了：s[0:5] 的新字符串头和母串指向同一个 Data 地址，只是 Len 不同。切片操作不产生任何内存分配。
不可变性：被共享倒逼出来的设计
为什么 Go 字符串不能改？因为共享。如果 sub := s[0:5] 之后允许 sub[0] = 'H'，母串 s 就被悄悄污染了——这种隐式联动是 bug 温床。不可变性一次性解决了三件事：
- 共享安全：子串、传参、赋值随便共享，谁也别想偷改；
- 能当 map key：内容不变，哈希值才稳定；
- 常量折叠：编译器把相同字面量合并进只读数据段，白省内存。
但共享也有代价——子串钉住母串内存。从 1GB 的日志里切出 10 个字节长期持有，那 1GB 就别想被 GC 回收。解法很简单，显式拷贝断开引用：
small := strings.Clone(huge[100:110]) // Go 1.20+, 等价于 string([]byte(...))
len 的坑：字节数 ≠ 字符数
输出第 3 行：len("你好") 是 6 不是 2。Go 源码按 UTF-8 编码，一个中文占 3 字节。len() 永远返回字节数；想要字符数，用 utf8.RuneCountInString（不分配内存）或 len([]rune(s))（要分配）。
遍历方式也跟着分叉：
for i := 0; i < len(s); i++ { s[i] } // 拿到的是 byte, 中文会被切碎
for _, r := range s { r } // 拿到的是 rune, 自动按 UTF-8 解码
处理中文时混用这两种遍历，是经典 bug 之源。
string 与 []byte：转换的两种姿势
输出第 4 行展示了一个关键事实：[]byte(s) 是拷贝。改 byte 切片不会影响原串——这正是为了维护不可变契约：如果返回的是共享数组，改 byte 就等于改了"不可变"的字符串。
但热点路径上每次转换都拷贝太奢侈，Go 1.20+ 给了官方零拷贝通道：
view := unsafe.String(&raw[0], len(raw)) // []byte -> string, 不拷贝
代价是责任转移：你必须保证只读。拿着 view 再去改 raw，就是未定义行为。
另外编译器会识别几个"不会逃逸"的惯用模式自动省拷贝：m[string(b)] 的 map 查找、string(b) == "x" 的比较、for range []byte(s) 的遍历。写热代码优先用这些写法。
拼接性能：Builder 的正确打开方式
循环里 s += part 每轮都产生新分配（旧串不可变无法复用），N 次拼接就是 N 次分配加拷贝。strings.Builder 内部维护一个 []byte 缓冲，所有写入只是追加，最后 String() 一次性产出结果：
var sb strings.Builder
sb.Grow(estimatedSize) // 已知大致长度就预分配, 省掉中间扩容
for _, p := range parts {
sb.WriteString(p)
}
result := sb.String()
两个使用纪律：Grow 先调（估算不准也无妨，估了总比不估强）；String() 之后别再写（Builder 是一次性的，内部有 copyCheck 会 panic）。要复用缓冲请换 bytes.Buffer。
小结
| 认知 | 一句话 |
|---|---|
| 结构 | string = {Data, Len}，16 字节，传参零拷贝 |
| 不可变 | 共享安全的根基，也是子串内存泄漏的根源 |
| 长度 | len 数字节，中文场景用 RuneCountInString |
| 转换 | 常规转换拷贝保契约，零拷贝仅限只读 |
| 拼接 | 循环拼接用 Builder + Grow，一次性使用 |
