go字符串底层是只读的stringheader结构体，含data指针和len长度字段，占16字节；无容量、无引用计数、不共享底层数组，赋值或切片可能触发拷贝。
Go 字符串底层到底是什么结构
Go 字符串不是字符数组，也不是指针加长度的简单组合，而是一个只读的、由 reflect.StringHeader 对应的 runtime 内部结构体 —— StringHeader。它在 unsafe 包里不可直接引用，但语义上等价于：
type StringHeader struct {
Data uintptr
Len int
}
这意味着：字符串变量本身仅占 16 字节（64 位系统），包含一个指向底层字节数组首地址的指针和一个长度值。没有容量（cap）、没有引用计数、不共享底层数组 —— 一旦赋值或切片，就可能触发新底层数组拷贝（取决于逃逸分析和编译器优化）。
为什么不能直接用 unsafe.String 转换任意指针
从 Go 1.20 开始，unsafe.String 成为安全转换函数，但它只接受 *byte 和长度，且要求：指针必须指向可寻址的、生命周期足够长的内存块。常见翻车点：
- 把栈上局部
[8]byte的地址传给unsafe.String(&arr[0], 8)—— 函数返回后栈帧回收，字符串变成悬垂指针 - 用
C.CString返回的*C.char直接转，没考虑 C 内存是否被C.free过 - 对
reflect.SliceHeader做类似操作，误以为结构体布局一致就能互转（实际StringHeader和SliceHeader的字段顺序一样，但语义不同，且 Go 不保证未来兼容）
string 和 []byte 互转的开销在哪
表面看 string(b) 和 []byte(s) 是零拷贝，但实际行为取决于上下文：
立即学习“go语言免费学习笔记（深入）”；
-
string([]byte)：如果切片底层数组未逃逸，且编译器能证明其只读，可能复用底层数组；否则会执行一次 memcpy —— 因为 string 必须只读，而[]byte可能被后续修改 -
[]byte(string)：总是分配新底层数组并拷贝，因为 string 的底层内存不可写，而切片需要可写空间 - 高频互转场景（如 HTTP body 处理）建议用
bytes.Buffer或预分配[]byte池，避免反复堆分配
用 unsafe.String 替代 string(unsafe.Slice(...)) 的时机
Go 1.20+ 推荐优先用 unsafe.String，而不是老式 (*[n]byte)(unsafe.Pointer(p))[:n:n] 风格。区别在于：
-
unsafe.String(p, n)明确表达“我要从 p 开始读 n 字节构造只读字符串”，编译器可做更多检查（比如 p 是否为空、n 是否溢出） - 旧方式依赖类型断言和切片头重写，容易因对齐、字段偏移变化失效（虽目前稳定，但属未文档化实现细节）
- 若 p 来自
mmap或硬件寄存器映射内存，需确保该内存页可读且不会被 OS 回收 —— 否则运行时 panic 不是“越界”，而是“段错误”
真正难处理的从来不是结构体字段怎么排，而是谁持有那块内存、何时释放、是否跨 goroutine 访问 —— 这些问题不会在 StringHeader 里写明，得靠你盯住内存生命周期。
