Go语言中字符串底层数据结构与内存分配机制剖析-Golang-PHP中文网

go字符串是只读结构体{str unsafe.pointer, len int}，16字节，仅存指针和长度，不存数据；str指向只读内存（如.rodata段），故无法修改，任何“修改”实为新建结构体并分配新内存。

go语言中字符串底层数据结构与内存分配机制剖析

Go 字符串不是字符数组，也不是可变缓冲区，而是一个固定大小的只读结构体。它本身不存数据，只存指针和长度 —— 这直接决定了你对 string 做任何“修改”操作时，本质上都是新建一个结构体，指向新内存。

Go 运行时中，string 对应的底层结构体（在 src/runtime/string.go 中定义）简化后是：

type stringStruct struct {
    str unsafe.Pointer
    len int
}

这个结构体大小固定为 16 字节（64 位系统下：8 字节指针 + 8 字节长度）。它不包含任何实际字节数据，str 字段只是一个指向某处只读字节数组首地址的指针。

str 指向的内存可能位于常量池（如字面量 "hello"）、堆（如 string([]byte{...}) 构造）、甚至栈（极少见，仅限逃逸分析未触发时的小量临时数据）
字符串不可变，是因为运行时不会允许你通过该结构体去写 *str 所指内存 —— 它被标记为只读（SRODATA 段），写入会触发 SIGSEGV
unsafe.Sizeof("a") 返回 16，不是 1；len("a") 返回 1，这才是真实内容长度

[]string 是切片，其 header 占 24 字节（data 指针 + len + cap），但它的 data 指向的不是 UTF-8 字节流，而是一块连续内存，里面挨个排布着多个 stringStruct 实例 —— 每个占 16 字节。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

例如 s := []string{"a", "bb", "ccc"}，底层数组共占用 cap(s) * 16 字节（注意是 cap，不是 len）
三个字符串的实际字节内容（1+2+3=6 字节）分散在别处，彼此地址不连续，也不跟底层数组相邻
执行 s2 := s[1:3] 时，s2 的 data 指向原底层数组第 2 个 stringStruct 的地址，不复制任何字符串内容，但整个底层数组（含所有 stringStruct）仍被 s 持有，无法 GC
如果原始 []string 很大（比如读日志生成的上万条记录），只取其中几条做长期缓存，就会拖住全部字符串内容，造成隐蔽内存泄漏

用切片语法取子串（如 s[10:20]）会复用原字符串的 str 指针和部分字节，只是调整 len 和偏移 —— 这很高效，但也很危险。

现象：large := make([]byte, 1 → <code>sub 虽然只有 10 字节逻辑长度，但它背后的 str 仍指向那 1MB 的 large 内存，只要 sub 活着，large 就不能回收
修复方式不是“避免切片”，而是显式复制：用 string(append([]byte(nil), sub...)) 或更清晰地 string([]byte(sub))（后者会触发新分配）
strings.Clone（Go 1.20+）是专为此设计的：它返回一个内容相同但独立分配的字符串，不共享底层内存

new(string) 返回的是 *string，即指向一个已分配、已零初始化的 stringStruct 的指针；而声明 var s string 直接得到一个值为 "" 的 string，其 str 为 nil、len 为 0。

两者都表示空字符串，但内存位置不同：new(string) 的结果一定在堆上（因为 new 总是分配堆内存），而 var s string 可能被分配在栈或全局数据段
*s = "hello" 是合法的，它把那个堆上的 stringStruct 的 str 和 len 字段填上新值；但你永远不能对 s[0] 赋值，因为那是试图写只读内存
不要用 new(string) 来“预分配缓冲区”——它不分配字符串内容空间，只分配结构体本身