Go字符串内存占用=16字节头大小+内容字节数，但实际取决于是否独占底层数组；len(s)仅返回UTF-8字节数，unsafe.Sizeof("")恒为16，reflect.StringHeader揭示其含Data指针和Len字段。
Go 字符串底层结构决定了它的内存占用不是 len() 那么简单
Go 中 string 是只读的不可变类型，底层由两个字段组成：指向底层字节数组的指针（uintptr）和长度（int）。所以实际内存占用 ≠ 字符串内容字节数，还要算上结构体头开销。
直接用 len(s) 只返回内容字节数（即 UTF-8 编码后的字节数），但不包括字符串头本身的内存。比如空字符串 "" 的 len() 是 0，但它仍占 16 字节（在 64 位系统上）。
-
unsafe.Sizeof("")返回 16 —— 这是字符串头固定大小（2 个uintptr或等效字段） -
len(s)返回内容字节数，和底层字节数组无关（因为可能共享底层数组） - 真正“字符串对象”总内存 ≈
unsafe.Sizeof(s) + len(s)，但仅当该字符串独占底层数组时才成立；若它只是某个大字节数组的切片视图，底层数组可能远大于len(s)
用 unsafe.Sizeof 获取字符串头大小，用 reflect.StringHeader 理解布局
Go 不暴露字符串头定义，但可通过 reflect.StringHeader 推断结构（注意：这是非安全操作，仅用于分析，不能用于生产逻辑）。
在 64 位系统上：
立即学习“go语言免费学习笔记（深入）”；
import "unsafe"
import "reflect"
s := "hello世界"
fmt.Println(unsafe.Sizeof(s)) // 输出 16
fmt.Printf("%+v\n", reflect.StringHeader{}) // {Data:0 Len:0}，说明含 uintptr Data 和 int Len
-
unsafe.Sizeof(s)永远返回 16（amd64），与内容无关 -
reflect.StringHeader字段顺序和大小与运行时一致，但直接构造或修改它会导致未定义行为 - 不要用
unsafe.Pointer(&s)去读取底层数据 —— Go 1.22+ 对字符串底层访问更严格，且 GC 可能移动底层数组
想估算“实际持有”的内存？得看是否逃逸、是否独立分配
字符串内容是否单独分配，取决于它如何创建：
- 字面量字符串（如
"abc"）存储在只读数据段，不计入堆内存，unsafe.Sizeof仍为 16，但内容不额外占堆 - 由
[]byte转换而来（如string(b)）会触发一次底层数组拷贝（除非编译器优化掉），此时实际占用 ≈ 16 + len(b) - 子串（如
s[2:5]）通常共享原底层数组 —— 它的len(s)小，但底层数组可能很大，GC 不会仅因子串存活就保留整个数组（Go 1.21+ 改进了子串逃逸判定） - 用
runtime.ReadMemStats或 pprof 测整体堆变化，比单个字符串“精确字节”更有实际意义
别被 “string size” 误导：没有标准 API 返回“完整占用字节数”
Go 标准库不提供类似 malloc_usable_size() 的函数来查字符串实际内存消耗，因为这本身是个模糊概念：是指头大小？内容大小？还是包含共享底层数组的全部容量？
-
len(s)是安全、常用、语义明确的 —— 表示 UTF-8 字节数 -
unsafe.Sizeof(s)是头大小，稳定但极少需要 - 试图通过
unsafe计算底层数组总长（比如从StringHeader.Data反推 cap）是错误的 —— 字符串没有容量（cap），只有切片才有 - 如果真要追踪内存，用
pprof抓堆快照，配合runtime.SetFinalizer观察生命周期，比手动算字节靠谱得多
真正难的不是算数字，而是理解哪些部分会被 GC 回收、哪些被长期持有 —— 这取决于字符串怎么来的，而不是它看起来多长。
