[]string底层是切片头+底层数组，每个string为16字节header（含指针和长度），不包含实际内容；真实内存需累加切片头24字节、headers共cap(s)×16字节、各字符串底层字节数组长度之和。
![go 语言中字符串切片 []string 的内存布局是怎样的](https://img.php.cn/upload/article/001/246/273/177719456889411.jpg)
字符串切片 []string 的底层是数组指针，不是字符串内容的连续块
Go 中 []string 的内存布局由两层组成：切片头（24 字节） + 底层数组（[n]string），而每个 string 本身又是 16 字节的 header（uintptr + int），不包含实际字节数据。所以它**绝不是**“把所有字符串内容拼在一起”的连续内存。
常见误解是认为 []string{"a", "bb", "ccc"} 在内存里连成一块：[a][bb][ccc] —— 实际上是：
- 底层数组存的是 3 个
string结构体（各 16 字节），共 48 字节； - 每个结构体里的
uintptr字段指向各自独立分配的字节数组（可能在堆、常量区或逃逸分析决定的位置）； - 这些字节数组彼此地址不连续，甚至可能跨页、跨 GC span。
为什么不能用 unsafe.Sizeof 计算真实内存占用
unsafe.Sizeof(s) 对 s []string 只返回 24（切片头大小），unsafe.Sizeof(s[0]) 返回 16（单个 string header 大小），但这两者加起来完全忽略实际字符串内容——比如 s[0] 指向的 "hello" 是 5 字节，s[1] 指向的 "world world world" 是 17 字节，这些必须单独累加。
容易踩的坑：
- 只看
cap(s) * 16就以为是总内存 → 漏掉所有底层字节数组； - 误以为
append(s, "x")会复用旧空间 → 实际可能触发底层数组扩容，新旧两块内存同时存在； - 用
reflect.SliceHeader强制转换时未校验Data是否有效 → 容易读到已回收内存或空指针。
字符串字面量和动态拼接的存储位置差异极大
同一个 []string 里，不同元素的底层字节可能来自完全不同的内存区域：
-
[]string{"foo", "bar"}：两个字面量大概率共享只读常量区，string.header.Data指向同一段内存的不同偏移； -
[]string{fmt.Sprintf("%d", i) for i := range make([]int, 100)}：100 个字符串各自在堆上独立分配，地址随机、无规律； - 混用时（如
[]string{"static", strconv.Itoa(123)}），底层数组仍是连续的（存 16 字节 headers），但 data 指针目标天差地别。
这意味着：哪怕你用 unsafe 遍历底层数组，也无法通过地址差推断出任意两个字符串内容是否相邻——它们根本不在一个逻辑内存块里。
想估算真实内存？必须分三步手动加总
计算 s []string 占用的总堆内存，需显式叠加：
-
24字节：切片头（固定）； -
cap(s) * 16字节：底层数组中所有stringheaders（不管len(s)多大，cap 决定已分配空间）； for i := 0; i ：所有字符串内容字节数之和（仅遍历当前有效元素，不包括 cap 中未初始化部分）。
注意：如果结构体里嵌套 []string（如 type User struct { Names []string }），还要额外加上该结构体自身的对齐填充 —— 这部分常被忽略，尤其当字段顺序不合理时，padding 可能多出十几个字节。
