string底层是字符数组（C++中为char*动态数组，Java中JDK9前为char[]、后优化为byte[]），含_size和_capacity成员，数据与元信息分离，c_str/data返回指向内容的指针。
[][]string 的底层是数组指针，不是字符串数据本身
go 中 []string 是切片类型，其 header（24 字节）包含 data（unsafe.pointer）、len 和 cap。但关键点在于：data 指向的是一块连续内存，里面存的不是字符串内容，而是 string 结构体实例 —— 每个占 16 字节（8 字节指针 + 8 字节长度），按顺序紧挨着排布。
也就是说，[]string 的底层数组存储的是「字符串头」，不是 UTF-8 字节序列本身。这些头各自指向不同位置的只读字节数组（可能在常量池、堆或栈上），彼此独立。
- 例如
s := []string{"a", "bb", "ccc"}，底层数组共占用3 × 16 = 48字节（不含 header） - 而实际字符数据（"a"、"bb"、"ccc"）分别额外占用 1+2+3 = 6 字节，且地址不连续、不相邻
- 如果某个
string是通过string([]byte{...})动态构造的，其字节数据在堆上分配；若是字面量，则大概率共享常量池
字符串字段导致切片内存不紧凑，无法用 unsafe.Sizeof 一概而论
unsafe.Sizeof(s) 只返回切片 header 大小（24 字节）；unsafe.Sizeof(s[0]) 返回单个 string 结构体大小（16 字节）；但这两者加起来完全不等于真实内存占用。
真实开销必须拆成三块计算：
-
24字节：切片 header -
cap(s) × 16字节：底层数组中所有string头的预留空间（注意是cap，不是len） -
sum(len(s[i]))字节：所有字符串内容的实际字节长度之和（仅内容，不含 header）
漏掉第三项，就会严重低估内存 —— 尤其当切片里存的是长日志行、JSON 片段或 base64 数据时，内容体积远超头信息。
从 []string 截取新切片不会复制字符串内容，但会共享底层数组头
执行 s2 := s[1:3] 时：
-
s2的Data指针指向原底层数组第 1 个string头的地址（即&s[1]） -
s2的Len=2、Cap=cap(s)-1（取决于原始切片是否带三索引表达式） - 所有
s2[i]仍指向各自原有的字节数据，没发生拷贝 - 只要
s还活着且未被 GC，它底层数组中全部string头都保持可达，哪怕s2是唯一引用它们的变量
这是常见内存泄漏源头：一个大 []string 被截取一小段后长期持有，却阻止整个底层数组（含大量字符串内容）被回收。
想控制内存局部性？别用 []string 存大量短字符串
如果你需要频繁遍历、缓存友好、或做 SIMD 处理，[]string 是糟糕选择 —— 它的字符串内容天然是离散的，cache line 利用率极低。
更紧凑的替代方案包括：
- 用单块
[]byte存所有字符数据，再配一个[]struct{ offset, len int }做索引 - 若字符串长度固定，改用
[N][M]byte数组（如固定 64 字节路径名） - 对只读场景，考虑
strings.Builder预分配后String()生成一次性字符串，避免切片长期持有多头
真正决定性能的，从来不是 []string 本身多占几个字节，而是它如何把原本可以线性的访问，变成随机跳转的指针链。
