StringHeader 是只读快照，Go 1.20+ 中修改会 panic；其固定 16 字节（Data 和 Len 各 8 字节，无 padding），不含 Cap，不存字符串内容，底层数据独立分配，不可写。
StringHeader 不是操作接口，而是只读快照；任何试图通过它修改字符串内容的代码，在 Go 1.20+ 中大概率直接 panic，而不是静默失败。
StringHeader 的字段和大小为什么固定为 16 字节
在 64 位系统上，StringHeader 占用严格 16 字节：Data 是 uintptr（8 字节），Len 是 int（8 字节），二者连续排列、无 padding。这和 SliceHeader（24 字节）不同——后者多一个 Cap 字段。
常见误解是认为 unsafe.Sizeof("hello") 返回的是字符串内容大小，其实它只测 header；无论 "" 还是 "a"，结果都是 16。
-
StringHeader里没有Cap字段，语言层面也不支持cap(s)操作 - 字符串内容（UTF-8 字节序列）永远不存于
StringHeader内，而是在常量池、堆或栈上独立分配 - 结构体中
string字段对齐值为 8，因含uintptr；编译器会自动插入 padding 确保起始地址 % 8 == 0
为什么不能用 StringHeader 修改字符串内容
字符串底层 Data 指针通常指向只读内存页（如字面量常量池），强行写入会触发 fatal error: unexpected signal 或 fault [signal 0xc0000005]。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
即使你绕过类型系统，用 unsafe.Pointer 把 StringHeader.Data 转成 *byte 并赋值，Go 运行时也会在 1.20+ 版本做运行时检查，非法指针转 string 直接 panic。
- 把
string转成[]byte再改内容，再转回string，原字符串不变——新string是全新分配的底层数组 -
unsafe.String构造的字符串是否可写，取决于源[]byte是否本身可写（比如来自make([]byte, N)且未逃逸） - 需要可变文本，请用
[]byte；要传给 C 函数，请用C.CString或显式分配可写内存
[]string 底层存的是 StringHeader，不是字符串内容
[]string 的底层数组里每个元素是完整的 StringHeader（16 字节），不是指针，也不是字节数据。这意味着：
- 数组本身只存“头”，所有实际字符数据分散在别处（常量池、堆、栈），彼此独立
-
unsafe.Sizeof(s)只返回切片 header（24 字节）；unsafe.Sizeof(s[0])返回单个StringHeader（16 字节）；但真实内存占用 = 24 + cap(s)×16 + 所有字符串内容字节数之和 - 截取子切片（如
s2 := s[1:3]）不复制字符串内容，但会共享底层数组中的StringHeader；只要原切片还活着，整个底层数组（含大量字符串内容）就无法被 GC 回收
哪些操作真正影响性能：对齐无关，逃逸才是关键
字符串本身不会因内存对齐逃逸；真正引发堆分配和 GC 压力的是拼接、转换等操作。
- 用
+拼接多个string会产生多个中间临时对象，全部逃逸到堆上 -
strings.Builder预分配底层数组，复用同一块内存；调用Grow()可显著减少 reallocation - 以下操作几乎必然逃逸：
return string(buf)（局部[]byte转换后返回）、fmt.Println(s)（传给interface{}）、闭包捕获局部string或其底层数组
验证是否逃逸，唯一可靠方式是 go build -gcflags="-m -l"，盯住输出里是否出现 escapes to heap —— 别猜，要实锤。
