Go：内存逃逸、栈堆分配、切片扩容、map 底层和 GC 应该怎么理解

发表于 分类于 本文字数： 6.2k 阅读时长 ≈ 23 分钟
围绕一个批量日志解析器，把 Go 里的内存逃逸、栈堆分配、slice 扩容、map 底层行为和 GC 串成一条完整的内存模型理解链，既能解释常见追问点，也能解释真实项目里的内存和性能现象。

代码评审和线上排障里，这几个词经常被连着提：内存逃逸、栈、堆、slice 扩容、map 底层、GC。

拆开看像一组零散概念，放回一段真实代码里，它们其实描述的是同一件事：对象在哪分配，谁持有它，容量怎么增长，什么时候释放，GC 要扫描多少内容。

一段日志处理代码里，常见的症状通常长这样：

  • 批量解析吞吐还能接受，但内存曲线持续上扬
  • append 之后，原切片里的数据也变了
  • map 遍历输出顺序每次都不一样
  • 只截了一小段 []byte，进程占用却一直下不来
  • allocs/op 比预期高，GC 次数也偏多

这篇文章不按词条背定义，而是围绕一个小场景把这些问题接成一条链：批量日志解析器。

一、这篇文章要解决什么问题

读完这一篇，应该能独立回答这些问题：

  1. Go 里的栈和堆分别适合承载什么样的对象
  2. 内存逃逸到底是什么意思，为什么它和 new、& 不是简单一一对应
  3. slice 为什么像“动态数组”，却又经常改到原数据
  4. map 底层到底是怎么做查找和扩容的，为什么遍历无序、并发写不安全
  5. GC 在这条链里到底看见了什么，哪些写法会放大 GC 压力
  6. 工程里怎么验证推断，而不是靠打印猜
  7. 短时间里怎么把这些概念组织成一段完整回答

如果这些点能串起来，后面写缓存、日志、批处理、聚合器、任务执行器时，内存相关的问题会更容易收束。

二、先给一个可复述的总回答

如果只给 60 到 90 秒，可以按下面这条顺序回答：

  1. 先讲分配位置
    Go 并不是按语法上的 new、& 来决定栈堆，而是由编译器做逃逸分析。当前函数栈帧内可以安全承载的对象优先放栈上，生命周期可能超过当前栈帧，或者编译器无法证明安全的对象，会放到堆上。

  2. 再讲 slice
    slice 不是数组本身，而是对底层数组的一层描述，包含指针、长度和容量。append 没超容量时，常常还在原数组上写；超了容量，就会分配新数组并搬迁数据。

  3. 再讲 map
    map 本质上是哈希表。查找均摊接近 O(1)，扩容时元素位置可能变化，所以遍历顺序不承诺稳定，元素也不能直接取地址改字段，并发写要做同步。

  4. 最后讲 GC
    堆对象越多、指针越多、被长时间持有的大块内存越多，GC 负担越重。逃逸、slice 扩容、map 里存指针，这三类写法都会直接影响堆大小和扫描成本。

  5. 落回工程结论
    工程里重点不是“消灭所有逃逸”，而是控制对象生命周期、减少不必要分配、避免误持有大底层数组、为热点结构做容量规划，并用 -gcflags=-m、benchmem、pprof 去验证。

后面的正文，就是把这段回答拆开。

三、贯穿全文的小场景：批量日志解析器

假设现在有一个最小批量日志解析器，它要做这几件事：

  1. 接收一批日志行
  2. 解析出服务名、状态码、耗时和消息
  3. 统计每个服务的请求数和错误数
  4. 记录最近几条错误日志
  5. 把聚合结果交给后续告警组件

原始输入先简化成字符串：

1
2
3
4
order-api,200,18,ok
order-api,500,34,db timeout
user-api,200,12,ok
billing-api,503,61,upstream unavailable

这个场景里几种结构的分工很清楚：

  • []string 或 [][]byte：承接一批动态长度输入
  • []Record：保存解析后的结果，涉及 slice 扩容和底层数组复用
  • map[string]ServiceStat：做按服务聚合
  • []Record 或 [N]Record：保存最近错误，用来对比动态切片和固定容量容器

也正是这几个结构，把栈堆、逃逸、GC 串到了一起。

四、先看最小可运行版本

先把最小版本立住：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
package parser

import (
	"strconv"
	"strings"
)

type Record struct {
	Service string
	Code    int
	CostMS  int
	Message string
}

type ServiceStat struct {
	Count      int
	ErrorCount int
	LastCodes  []int
}

type Report struct {
	Records      []Record
	Stats        map[string]ServiceStat
	RecentErrors []Record
}

func Process(lines []string) Report {
	report := Report{
		Records:      make([]Record, 0, len(lines)),
		Stats:        make(map[string]ServiceStat, len(lines)),
		RecentErrors: make([]Record, 0, 8),
	}

	for _, line := range lines {
		parts := strings.SplitN(line, ",", 4)
		if len(parts) != 4 {
			continue
		}

		code, err := strconv.Atoi(parts[1])
		if err != nil {
			continue
		}
		cost, err := strconv.Atoi(parts[2])
		if err != nil {
			continue
		}

		record := Record{
			Service: parts[0],
			Code:    code,
			CostMS:  cost,
			Message: parts[3],
		}
		report.Records = append(report.Records, record)

		stat := report.Stats[record.Service]
		stat.Count++
		if record.Code >= 500 {
			stat.ErrorCount++
			stat.LastCodes = append(stat.LastCodes, record.Code)
			report.RecentErrors = append(report.RecentErrors, record)
		}
		report.Stats[record.Service] = stat
	}

	return report
}

这段代码已经把本文的几个关键问题都带出来了：

  • record 这个局部变量到底放栈还是堆
  • report.Records 什么时候会扩容
  • stat.LastCodes 为什么有时会反复分配
  • map 里的 ServiceStat 为什么要读出来、改完、再写回去
  • RecentErrors 持有的对象会不会拉高 GC 压力

五、栈和堆先怎么区分

先把两个概念摆正：

  • 栈更适合承载生命周期短、大小相对可控、作用域清晰的对象
  • 堆更适合承载生命周期跨函数、被多个对象共享、大小或生存期难以静态证明的对象

在 Go 里，栈对象和堆对象最关键的区别不是“谁更高级”，而是：

  1. 栈对象跟随函数栈帧创建和回收，离开作用域后回收路径很直接
  2. 堆对象由运行时统一管理，何时回收取决于是否还可达
  3. 堆对象一旦变多，就会把 GC 扫描成本带起来

最小例子：

1
2
3
4
func sum(a, b int) int {
	total := a + b
	return total
}

这里的 total 生命周期只在函数内部，通常适合放在栈上。

再看另一个例子：

1
2
3
4
func newCount() *int {
	n := 1
	return &n
}

n 的地址被返回后，生命周期已经超过当前函数栈帧，编译器通常会把它安排到堆上。

六、内存逃逸到底是什么

内存逃逸的核心定义可以压成一句话：

一个对象本来有机会放在当前函数栈上，但它的引用需要活得更久，或者编译器无法证明栈上安全，于是把它放到了堆上。

这个定义里有两个重点：

  1. 逃逸是编译器分析结果
  2. 逃逸判断看的是生命周期和可证明性

所以这几组关系都不是简单等号：

  • new(T) 不等于一定上堆
  • &x 不等于一定上堆
  • 返回值是值类型，不等于一定不逃逸
  • 没写指针，不等于堆分配就不会发生

一个例子能看清这件事：

1
2
3
4
5
6
7
func buildRecord(service string, code int) *Record {
	record := Record{
		Service: service,
		Code:    code,
	}
	return &record
}

这里不是因为用了 &record 这行语法才显得“危险”，真正的原因是：返回后调用方还要继续使用这个对象。

七、哪些写法最容易让对象逃到堆上

工程里最常见的几类触发点如下：

1. 返回局部变量的地址

1
2
3
4
func buildCounter() *int {
	n := 0
	return &n
}

2. 闭包或 goroutine 持有局部变量

1
2
3
4
5
6
func spawn(records []Record) func() int {
	count := len(records)
	return func() int {
		return count
	}
}

闭包返回后仍然要读 count，编译器往往需要把相关对象放到更长寿命的位置。

3. 把对象放进堆上的容器

例如切片扩容后的底层数组、map 内部结构、长寿命对象字段，都会延长引用链。

1
2
3
4
5
6
7
8
func collect(lines []string) []*Record {
	out := make([]*Record, 0, len(lines))
	for _, line := range lines {
		r := &Record{Service: line}
		out = append(out, r)
	}
	return out
}

这里每个 Record 都会跟着 out 一起活下去。

4. 大对象或大小难以静态确定的对象

这类场景不要求每次都上堆，但编译器更难在栈上做保守而高效的安排。

5. 接口装箱之后生命周期继续外扩

接口本身不是“逃逸开关”，但如果一个值装进接口后，需要在当前函数之外继续存在，或者被放进长寿命结构里，也可能引出堆分配。

八、怎么用编译器验证逃逸结论

讨论逃逸时，最稳的做法不是只看代码外形，而是直接看编译器结论。

常用命令：

1
go build -gcflags="-m=2" ./...

对单文件实验，也可以直接：

1
go build -gcflags="-m=2" main.go

输出里经常能看到类似信息：

1
2
3
./main.go:14:2: moved to heap: record
./main.go:20:9: &Record{...} escapes to heap
./main.go:27:14: make([]Record, 0, len(lines)) escapes to heap

这里有两个阅读要点：

  1. 具体措辞会随 Go 版本变化
  2. 重点不是逐字背输出，而是看谁在逃逸、为什么逃逸

如果看到某个对象逃逸，不要立刻把它归类成“坏代码”。下一步更重要：这个对象是不是热点路径上的短命对象，它的数量是不是会在高并发下快速放大。

九、逃逸不是原罪，关键看对象生命周期

逃逸本身不是 bug，也不是需要被清零的指标。

有些对象放堆上是合理的，甚至是表达语义最清楚的方式：

  • 结果对象需要在多个组件间共享
  • 缓存条目本来就要长期存在
  • 请求上下文要跨多个函数流转
  • goroutine 闭包需要读取外部状态

工程里更有价值的问题是：

  1. 这些堆对象是不是必要
  2. 这些对象会不会在热点路径里大量产生
  3. 这些对象有没有被意外持有太久
  4. 它们是不是包含太多指针，导致 GC 扫描变重

例如 map[string]*ServiceStat 和 map[string]ServiceStat 都能写，但两者的对象数量、指针数量和可变方式并不一样，后面会展开。

十、切片为什么总和扩容绑在一起

理解 slice，先记住它不是“变长数组”这句口语化描述本身，而是要记住它的三个字段：

  1. 指向底层数组的指针
  2. 长度 len
  3. 容量 cap

也就是说，slice 自己只是一个小描述符，真正存元素的是底层数组。

最小例子：

1
2
base := []int{10, 20, 30, 40}
part := base[:2]

此时：

  • part 长度是 2
  • part 容量通常还是从起始位置到底层数组末尾的长度
  • part[0]、part[1] 和 base 共享同一块底层数组

append 的行为也就顺理成章了：

  1. 追加后如果没超 cap，还在原底层数组上写
  2. 追加后如果超 cap，运行时会分配新的底层数组，把旧数据搬过去，再写新元素

如果只答“slice 会自动扩容”，信息量还不够。更关键的是把“扩到哪里、会不会共享原数组”说出来。

十一、切片扩容后为什么有时影响原数据

这是 slice 题里最常被追问的一段。

先看例子：

1
2
3
4
5
6
7
8
base := []int{1, 2, 3, 4}

a := base[:2]
b := append(a, 9)

fmt.Println(base)
fmt.Println(a)
fmt.Println(b)

如果 a 追加时容量还够，9 会直接写进 base 的后续位置，结果通常接近：

1
2
3
[1 2 9 4]
[1 2]
[1 2 9]

再看另一个版本：

1
2
3
4
base := []int{1, 2}

a := base[:2]
b := append(a, 9)

这里原切片容量已经满了，append 会触发扩容，b 很可能拿到一块新数组，base 不会被改。

这就是为什么看起来同样的 append，结果却不同。
决定因素不是“是不是 append”，而是追加时有没有复用原底层数组。

如果明确不想共享底层数组，可以这样截断容量：

1
2
a := base[:2:2]
b := append(a, 9)

也可以主动复制：

1
2
b := append([]int(nil), a...)
b = append(b, 9)

十二、错误示例：小切片拖住大底层数组

这是排内存问题时非常高频的一类坑。

假设解析器一次把整个批次文件读进内存：

1
2
3
4
5
6
7
8
func pickPrefix(batch []byte) []byte {
	for i, b := range batch {
		if b == '\n' {
			return batch[:i]
		}
	}
	return batch
}

如果 batch 是 32MB 的大缓冲区，pickPrefix 返回的只是前几十个字节，但它依旧引用着原来那 32MB 底层数组。

后面哪怕只把这小段结果放进一个长寿命切片里，整块大内存都还活着。

更稳的写法是主动复制需要的部分：

1
2
3
4
5
6
7
8
func pickPrefix(batch []byte) []byte {
	for i, b := range batch {
		if b == '\n' {
			return append([]byte(nil), batch[:i]...)
		}
	}
	return append([]byte(nil), batch...)
}

这个例子和 GC 的关系很直接：
GC 回收的是不可达对象，不是“你主观上不想要的那部分字节”。
只要还有一个小切片指向大数组，大数组就还可达。

十三、切片容量规划怎么做更稳

写批处理、聚合器、日志解析器时，slice 的容量规划很有价值，因为它直接影响两件事：

  1. 分配次数
  2. 数据搬迁次数

几个常用策略：

1. 已知上界时预分配

1
records := make([]Record, 0, len(lines))

2. 只保留最近 N 条时做环形窗口或固定上界

如果 RecentErrors 只需要最近 8 条，没必要让它无限长。

1
2
3
if len(report.RecentErrors) < 8 {
	report.RecentErrors = append(report.RecentErrors, record)
}

或者直接用固定大小数组加下标轮转。

3. 长寿命切片里少放大对象指针

如果切片本身要活很久，里面塞满指针会增加堆对象数量和 GC 扫描成本。
短小结构体按值存储，往往更紧凑。

4. 处理完大切片后及时断开引用

局部变量离开作用域后自然会失效；如果它被更长寿命对象持有，就需要显式改写引用关系。

十四、map 底层到底在解决什么问题

把 map 先放回抽象层看，它解决的是：按 key 快速定位 value。

Go 的 map 本质上是哈希表。对外需要记住的是这几个稳定事实：

  1. key 会先参与哈希计算
  2. 哈希结果会决定元素落到哪个桶或组
  3. 冲突发生时，需要在同桶或同组里继续比较
  4. 装载变高后，map 会增长，元素位置可能变化

不同 Go 版本会调整具体布局和增长细节，但下面这些行为是写业务和解释现象都绕不过去的：

  • 查找、插入、删除平均复杂度接近 O(1)
  • 遍历顺序不承诺稳定
  • 扩容时元素位置可能变化
  • key 需要可比较
  • 一旦有并发写，就需要同步保护

在日志解析器里，map[string]ServiceStat 就是在做“按服务名聚合”的工作。
不用 map，通常就要退回到线性扫描，复杂度会从一批 O(n) 聚合退化出额外成本。

十五、map 为什么无序、为什么并发写不安全

1. 遍历无序

map 的目标是高效查找，不是维持插入顺序。
元素经过哈希分布后，本来就不会天然保留“录入顺序”。

所以下面这种写法不应该作为稳定输出依赖：

1
2
3
for service, stat := range report.Stats {
	fmt.Println(service, stat.Count)
}

如果要稳定输出，做法通常是：

  1. 先把 key 收集到切片
  2. 排序
  3. 再按序读取 map

2. 并发写不安全

map 在运行时可能扩容、搬迁、更新内部状态。
多个 goroutine 同时写，或者一边写一边没有同步地读，都会破坏内部一致性。

一个经验判断可以这样记：

  • 纯并发读，且期间没有写入，通常可行
  • 只要引入写，就该加锁、分片锁，或者评估 sync.Map

日志解析器如果并发汇总多个批次，直接共享一个普通 map 写入，风险就会立刻出现。

十六、map 元素为什么不能直接取地址改字段

看这段代码：

1
2
3
4
5
6
7
8
9
10
11
type ServiceStat struct {
	Count int
}

func bad() {
	m := map[string]ServiceStat{
		"order-api": {Count: 1},
	}

	m["order-api"].Count++
}

这段代码编译不过。
原因不在语法挑剔，而在于 map 扩容后元素位置可能变化，运行时不能向你承诺这个元素地址长期稳定。

正确写法通常是“取值、修改、写回”：

1
2
3
stat := m["order-api"]
stat.Count++
m["order-api"] = stat

如果确实需要频繁原地修改，也可以把 value 设计成指针：

1
2
3
4
5
m := map[string]*ServiceStat{
	"order-api": {Count: 1},
}

m["order-api"].Count++

但这个选择会引入新的工程权衡：

  • 多了额外堆对象
  • 多了更多指针
  • GC 扫描成本会变高

这就是“性能优化不能只看写法顺不顺手”的典型例子。

十七、错误示例：nil map、值修改和热点 key

map 相关的高频坑，工程里通常集中在这几类。

1. nil map 可以读，写会 panic

1
2
3
var m map[string]int
fmt.Println(m["x"]) // 0
m["x"] = 1          // panic

修复方式很直接：

1
m := make(map[string]int)

2. 误把 map value 当成可原地修改对象

1
2
3
4
5
6
7
8
type Item struct {
	Count int
}

func bad() {
	m := map[string]Item{"a": {Count: 1}}
	m["a"].Count = 2
}

要么读改写回，要么改成指针 value。

3. 热点 key 下的字符串拼接和临时对象

1
2
key := service + ":" + strconv.Itoa(code)
stats[key]++

如果这段在高频路径上持续构造临时字符串，分配和哈希开销都会被放大。
这时就要评估：

  • key 设计是否过于临时
  • 是否能拆成多级结构
  • 是否能复用已有字段，减少中间对象

十八、GC 在这条链里扮演什么角色

GC 不是孤立存在的末尾章节，它贯穿整条链。

高层理解可以抓这几个点：

  1. Go 运行时会从根对象出发，标记仍然可达的堆对象
  2. 不可达的堆对象才有机会在后续阶段被回收
  3. 为了减少长时间停顿，Go 会把大部分 GC 工作做成并发执行
  4. 但再怎么并发，堆对象数量、指针数量、存活对象规模，仍然会影响 GC 总成本

所以 GC 的视角不是“这段代码优不优雅”，而是：

  • 有多少堆对象
  • 这些对象之间有多少引用
  • 哪些对象会活过多轮 GC
  • 哪些对象其实已经没业务价值，但还被引用链挂着

这也是为什么内存问题排查时，光盯着“哪行分配了对象”还不够，还要看“谁把它留住了”。

十九、逃逸、slice、map 怎么一起影响 GC 压力

把前面几个概念接起来，GC 压力通常来自下面这几条链路。

1. 逃逸让短命对象进入堆

局部对象如果本来能在栈里结束，却因为返回地址、闭包持有、长寿命引用而进入堆，就会进入 GC 管辖范围。

2. slice 扩容会制造新的底层数组

热点路径上持续扩容，就会不断申请新数组并搬迁数据。
旧数组何时释放，取决于是否还有引用。

3. 小切片误持有大数组会拉高存活内存

这类问题最隐蔽，因为代码里看见的是几十字节，堆上活着的却可能是几十 MB。

4. map 里放指针会增加对象数和扫描边

map[string]*ServiceStat 修改起来方便，但对象更多、指针更多。
map[string]ServiceStat 读改写回稍显啰嗦，但对象通常更集中。

5. 长寿命缓存结构会把短命数据变成长命数据

如果解析器把整批 Record 都挂进一个长期存在的缓存，哪怕单次请求结束了，这批对象也还在。
从 GC 角度看，这不是“本轮请求的临时数据”，而是“服务级常驻数据”。

二十、怎么用测试和基准把判断落地

写这类代码时，比较稳的验证链路是三件套：

  1. 单元测试验证行为正确
  2. 基准测试验证时间和分配
  3. profile 验证热点和保活关系

先看一个最小测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
func TestProcess(t *testing.T) {
	lines := []string{
		"order-api,200,18,ok",
		"order-api,500,34,db timeout",
		"user-api,200,12,ok",
	}

	report := Process(lines)

	if got := report.Stats["order-api"].Count; got != 2 {
		t.Fatalf("order-api count = %d, want 2", got)
	}
	if got := report.Stats["order-api"].ErrorCount; got != 1 {
		t.Fatalf("order-api error count = %d, want 1", got)
	}
	if len(report.RecentErrors) != 1 {
		t.Fatalf("recent errors = %d, want 1", len(report.RecentErrors))
	}
}

再看一个基准：

1
2
3
4
5
6
7
8
9
10
11
func BenchmarkProcess(b *testing.B) {
	lines := make([]string, 0, 10000)
	for i := 0; i < 10000; i++ {
		lines = append(lines, "order-api,500,34,db timeout")
	}

	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		_ = Process(lines)
	}
}

执行：

1
go test -bench=. -benchmem

这里重点看：

  • ns/op
  • B/op
  • allocs/op

如果只是把 ns/op 降下来了，allocs/op 却明显上去了，就还不能说这次修改是健康的。

二十一、线上排障该从哪里下手

线上出现内存上涨、GC 偏频繁、吞吐掉下去时，排查顺序可以比较固定：

1. 先看是不是分配太多

  • benchmark 的 allocs/op
  • pprof 的 alloc_space
  • 热点路径是不是在反复造临时对象

2. 再看是不是保活太久

  • heap profile 里哪些对象活着
  • 是谁在引用它们
  • 有没有小切片挂住大数组

3. 再看是不是结构选型带来的扫描成本

  • map[string]*T 是否真的有必要
  • 长寿命切片里是不是塞了太多指针
  • 大对象是否被缓存层长时间持有

4. 最后再考虑局部技巧

  • 预分配容量
  • 减少中间字符串
  • 缩短对象生命周期
  • 用值语义替代部分指针语义

如果需要进一步观察 GC 节奏，可以打开：

1
GODEBUG=gctrace=1 ./your-app

它能帮助判断 GC 频率、暂停和堆规模是否异常。

二十二、边界条件别漏

这几个边界条件在讨论和项目里都很容易被追问：

1. new(T) 不是“堆分配关键字”

它表达的是“拿到一个 *T”，到底栈还是堆，仍然看逃逸分析。

2. make 也不是“只在栈上”

slice、map、chan 的底层结构最终在哪，依然看具体生命周期和实现需要。

3. nil slice 和 nil map 行为不同

  • nil slice 可以 append
  • nil map 读可以，写会 panic

4. 删除 map 元素后，空间不代表会立刻回到初始水平

如果业务规模经历过峰值，后面长期规模已经明显下降，重建 map 往往比指望“自动缩回去”更可控。

5. 返回小结构体值，未必比返回指针差

如果结构体不大，按值返回可能更简单，也更有机会留在栈上。
这里要结合大小、复制成本、调用频率一起判断。

二十三、练习题

可以拿下面几题自测一下是否真正串起来了：

  1. 为什么下面这段代码里，append 之后 base 也可能被改？
1
2
3
4
base := []int{1, 2, 3, 4}
a := base[:2]
b := append(a, 99)
_ = b

  1. map[string]Stat 和 map[string]*Stat 该怎么选？
    从修改便利性、对象数量、GC 扫描成本三个维度各说一遍。

  2. 批处理代码把 64MB 日志块读入 buf，再把每一行的前缀保存进 [][]byte。
    如果内存迟迟下不来，优先怀疑哪类问题，怎么修。

  3. 一个局部变量写成 new(T)、&T{}、普通值变量三种形态后，是否上堆，应该用什么办法验证。

  4. 线上 allocs/op 很高，但 CPU 还没明显拉满。
    这时先看哪个指标，为什么不能只盯住耗时。

二十四、结语

把这组高频题真正串起来，主线其实并不复杂：

  1. 编译器先决定对象更适合放栈还是堆
  2. slice 决定一段连续内存如何被共享和扩容
  3. map 决定按 key 索引的数据如何组织和迁移
  4. GC 负责回收不再可达的堆对象，并为仍然存活的对象付出扫描成本

工程里真正重要的，不是把每个术语背成孤立定义，而是能顺着一段代码回答下面这几个问题：

  • 这个对象为什么会活这么久
  • 这次 append 会不会复用原数组
  • 这个 map value 设计成值还是指针更合适
  • 哪些对象进入了堆，哪些对象只是被误持有
  • 这次内存上涨到底是分配变多了，还是释放变慢了

把这条链讲清，回答会更完整。
项目里把这条链用测试、基准和 profile 验证清楚，代码会更稳。