Go字符串是只读结构体{str unsafe.Pointer, len int}，16字节，仅存指针和长度，不存数据；str指向只读内存（如.rodata段），故无法修改，任何“修改”实为新建结构体并分配新内存。
Go 字符串不是字符数组，也不是可变缓冲区，而是一个固定大小的只读结构体。它本身不存数据，只存指针和长度 —— 这直接决定了你对 string 做任何“修改”操作时，本质上都是新建一个结构体，指向新内存。
string 类型的 runtime 结构体长什么样
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 的底层数组存的是什么
[]string 是切片，其 header 占 24 字节（data 指针 + len + cap），但它的 data 指向的不是 UTF-8 字节流，而是一块连续内存，里面挨个排布着多个 stringStruct 实例 —— 每个占 16 字节。
立即学习“go语言免费学习笔记（深入）”；
- 例如
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 零值的区别
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)来“预分配缓冲区”——它不分配字符串内容空间，只分配结构体本身
真正容易被忽略的点在于：字符串内容和它的结构体是分离的，而 Go 的很多 API（比如 fmt.Sprintf、strings.Builder.String()）返回的 string 都可能背后连着一大块你没意识到的内存。盯住 str 指针的来源，比盯住 len 更重要。
