[]string底层是切片头+底层数组，每个string为16字节header（含指针和长度），不包含实际内容；真实内存需累加切片头24字节、headers共cap(s)×16字节、各字符串底层字节数组长度之和。

字符串切片 []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 里，不同元素的底层字节可能来自完全不同的内存区域：

使用Go语言搭建家庭相册系统-相关课件

使用Go语言搭建家庭相册系统-相关课件

下载

• []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 字节：底层数组中所有 string headers（不管 len(s) 多大，cap 决定已分配空间）；
• for i := 0; i ：所有字符串内容字节数之和（仅遍历当前有效元素，不包括 cap 中未初始化部分）。

注意：如果结构体里嵌套 []string（如 type User struct { Names []string }），还要额外加上该结构体自身的对齐填充 —— 这部分常被忽略，尤其当字段顺序不合理时，padding 可能多出十几个字节。