Go：值类型、引用语义、指针到底应该怎么理解

发表于 2018-05-09 分类于 Go 本文字数： 5.2k 阅读时长 ≈ 19 分钟

围绕一个轻量任务执行器，把 Go 里最容易混淆的值类型、切片和 map 的引用式表现、指针、函数传参与副作用讲清楚，并给出测试、排障和工程判断。

学到这里时，往往会同时冒出几种互相打架的说法：

Go 里一切都是值传递
slice 和 map 明明又像“引用类型”
struct 说是值类型，里面放个 slice 又会串改
该不该用指针，最后很容易变成“全都加 *”

这几句话单看都像对，拼在一起就很容易把人绕晕。

真正的问题通常不是语法，而是对象边界和副作用边界没建立起来。
一旦这层没搞清楚，真实项目里很快就会出现这些情况：

函数改了参数，调用方的数据也变了
以为 append 成功了，结果外层长度没变
以为 struct 复制后已经隔离，结果里面的标签还是串了
为了“保险”到处传指针，最后代码谁在改谁根本说不清

这篇文章就围绕一个很实际的小场景来讲：做一个轻量任务执行器的批次装配逻辑。
这个场景里会自然碰到：

struct 拷贝
slice 共享底层数组
map 的共享修改
指针带来的原地变更
函数边界到底该返回新值还是修改原值

把这条线真正理顺，后面再学 struct、方法集、interface、并发时，脑子会清楚很多。

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

读完这一篇，应该能独立说清这些事：

Go 为什么说“参数传递永远是值传递”
为什么 slice、map、chan 看起来又像引用
struct 复制时，到底哪些字段会真正隔离，哪些不会
指针参数到底在帮你做什么，又会带来什么风险
写函数时，什么时候该返回新值，什么时候该传指针
遇到数据串改时，怎么快速判断是值拷贝问题，还是共享底层数据问题

如果这些动作能独立做出来，后面再写 HTTP 服务、命令行工具、任务调度器，代码会稳很多。

二、先把场景说清楚

假设现在要做一个最小的任务执行器，它负责把一批回归任务装配出来，然后交给后面的 worker 执行。

先定义两个最小结构：

type Job struct {
	ID     string
	Status string
	Labels []string
}

type Batch struct {
	Name     string
	Jobs     []Job
	Counters map[string]int
}

这个小场景里会有四类很典型的操作：

给批次改名
把某个任务标记为失败
追加标签
更新统计计数

看起来都很简单，但它们对“值语义”和“共享状态”的要求完全不一样。

三、先看一个最小例子：为什么说 Go 里都是值传递

先看最简单的一段代码：

package main

import "fmt"

type Job struct {
	ID     string
	Status string
}

func markDone(job Job) {
	job.Status = "done"
}

func main() {
	job := Job{ID: "case-001", Status: "pending"}
	markDone(job)
	fmt.Println(job.Status)
}

输出：

pending

第一次看到这里时，常见结论是：“说明 struct 是值类型。”

这句话不算错，但还不够。真正更底层的说法是：

调用 markDone(job) 时
传进去的是 job 这个值的一份副本
函数里改的是副本，不是外面的原对象

Go 里函数传参、赋值、返回值，默认都遵循这个规则：复制值。

这个结论先记住，因为后面所有现象都从这里长出来。

四、Go 里到底有没有“引用类型”

严格一点说，Go 学习时最容易把人带偏的一句话就是“某某是引用类型”。

更稳的理解方式是：

Go 的赋值和传参都在复制值
只是有些值本身就包含“指向底层数据的描述信息”
所以复制之后，多个变量仍然可能共享同一份底层数据

先做一个实用层面的分类：

明显按值表现的：bool、int、float64、string、array、大多数纯标量 struct
带明显引用式行为的：slice、map、chan、函数值里捕获的闭包环境
指针本身也是值，只不过它保存的是地址

这也是为什么这篇文章里更适合用“引用语义”这个词，而不是简单说“引用类型”：

slice 复制的是切片头
map 复制的是 map 变量内部的运行时描述
*T 复制的是地址值

它们全都还是在复制值，只是复制后的值还能连到同一块底层数据。

五、真正的值拷贝到底长什么样

先看数组。

package main

import "fmt"

func main() {
	a := [3]int{1, 2, 3}
	b := a
	b[0] = 99

	fmt.Println(a)
	fmt.Println(b)
}

输出：

1 2	[1 2 3] [99 2 3]

这里很直观：

b := a 得到的是一份新数组
改 b 不会影响 a

再看 struct。

type Job struct {
	ID     string
	Status string
}

func main() {
	a := Job{ID: "case-001", Status: "pending"}
	b := a
	b.Status = "done"

	fmt.Println(a.Status)
	fmt.Println(b.Status)
}

输出：

1 2	pending done

到这里都没问题。
真正让人开始困惑的是：struct 自己按值复制，但它的字段不一定都是“彻底独立”的。

六、struct 是值类型，但里面的字段可能不是“彻底值化”

看下面这个例子：

package main

import "fmt"

type Job struct {
	ID     string
	Labels []string
}

func main() {
	a := Job{
		ID:     "case-001",
		Labels: []string{"smoke", "ui"},
	}

	b := a
	b.ID = "case-002"
	b.Labels[0] = "api"

	fmt.Println(a.ID, a.Labels)
	fmt.Println(b.ID, b.Labels)
}

输出：

1 2	case-001 [api ui] case-002 [api ui]

为什么 ID 没串，Labels 却串了？

因为这里发生了两层复制：

b := a，整个 Job struct 被复制了一份
但 Labels 这个字段本身是一个 slice 值
slice 值里带着“底层数组指针 + 长度 + 容量”
复制 struct 时，Labels 这个切片头也被复制了
两个切片头仍然指向同一个底层数组

所以结果就是：

ID 这种纯值字段，已经隔离
Labels 这种带共享底层数据的字段，仍然会联动

这类问题在真实项目里特别高频，因为配置对象、请求对象、任务对象里经常都有 slice 和 map 字段。

七、slice 为什么最容易让人误判

Go 的 slice 最容易制造两种错觉：

错觉一：它像引用，所以怎么改都会影响外面
错觉二：它是值，所以函数里怎么改都不会影响外面

这两个判断都不完整。

先看第一种最常见情况：改元素会影响调用方。

package main

import "fmt"

func markFirstFailed(statuses []string) {
	statuses[0] = "failed"
}

func main() {
	statuses := []string{"pending", "running"}
	markFirstFailed(statuses)
	fmt.Println(statuses)
}

输出：

1	[failed running]

原因是：

函数拿到的是 slice 头的一份副本
但副本和原 slice 头指向同一个底层数组
改元素，本质上是在改共享的底层数组

再看第二种情况：append 不一定让调用方看到长度变化。

package main

import "fmt"

func addAuditLine(lines []string) {
	lines = append(lines, "job finished")
	fmt.Println("inside:", len(lines), cap(lines), lines)
}

func main() {
	lines := make([]string, 1, 2)
	lines[0] = "job started"

	addAuditLine(lines)
	fmt.Println("outside:", len(lines), cap(lines), lines)
	fmt.Println("reslice:", lines[:2])
}

可能输出：

1
2
3

inside: 2 2 [job started job finished]
outside: 1 2 [job started]
reslice: [job started job finished]

这段代码特别值得反复看。

函数里明明 append 成功了，为什么外面长度还是 1？

因为：

append 改的是函数内部那份 slice 头副本
调用方自己的 slice 头长度没有变
但由于容量够用，新增元素仍然写进了共享底层数组

所以这类 bug 最麻烦的地方在于：

外层看长度，好像没成功
真去 reslice 或复用底层数组时，数据又已经被污染了

这就是为什么工程里更稳的习惯通常是：

只要函数里可能 append，就把结果返回给调用方

例如：

1
2
3

func addAuditLine(lines []string, line string) []string {
	return append(lines, line)
}

调用方明确接住返回值：

1	lines = addAuditLine(lines, "job finished")

这比单靠记住容量细节稳得多。

八、map 为什么也像引用，但又不该默认传 `*map`

map 的行为和 slice 很像，但又不完全一样。

先看最常见的例子：

package main

import "fmt"

func increaseFailed(stats map[string]int) {
	stats["failed"]++
}

func main() {
	stats := map[string]int{"failed": 0}
	increaseFailed(stats)
	fmt.Println(stats["failed"])
}

输出：

这很容易让人得出结论：“map 是引用类型。”

更准确的说法是：

stats 这个 map 变量被复制了一份
但副本和原变量都指向同一张底层哈希表
所以改键值对时，双方都能看到

但下面这段又很容易把这件事讲乱：

func reset(stats map[string]int) {
	stats = make(map[string]int)
	stats["failed"] = 0
}

如果调用：

1
2
3

stats := map[string]int{"failed": 3}
reset(stats)
fmt.Println(stats["failed"])

输出仍然是：

因为这里改的是：

函数内部那个 map 变量副本
让它重新指向了一张新表
外面的原 map 变量根本没变

所以 map 的工程判断通常是：

要修改已有 map 里的键值对，直接传 map
要替换成一张新 map，返回新 map
大多数情况下，不需要 *map

还有一个高频坑不能漏：nil map 只能读，不能写。

1 2	var stats map[string]int stats["failed"]++

这会直接 panic：

1	panic: assignment to entry in nil map

这类问题很常见，因为零值 map 看起来和空 map 很像，但它根本没初始化。

九、指针到底是什么，它解决了什么问题

指针没那么玄，它本质上只是“保存某个对象地址的值”。

例如：

1
2
3

func markRetrying(job *Job) {
	job.Status = "retrying"
}

调用：

1
2
3

job := Job{ID: "case-001", Status: "pending"}
markRetrying(&job)
fmt.Println(job.Status)

输出：

retrying

这里发生的事是：

&job 取到了 job 的地址
函数参数接收的是这个地址值的一份副本
通过这个地址，函数可以定位并修改原来的 job

所以指针不是“让 Go 改成引用传递”，而是：

仍然在复制值
只是复制的值恰好是地址

这也是最容易讲清楚的一句话：

Go 没有按引用传参，只有“把地址这个值传进去”。

十、函数传参到底怎么选，先看语义，不要先看语法

真实项目里最重要的不是“会不会写 *”，而是先把函数语义说清楚。

可以先问自己四个问题：

这个函数是要修改调用方对象，还是只基于输入算结果
这个类型里有没有 slice、map 这类共享字段
这个函数会不会 append 或重建内部字段
调用方能不能从函数签名一眼看出副作用

下面是几种常见写法。

1. 只想基于输入返回新结果，就传值并返回值

func normalizeJob(job Job) Job {
	job.Status = "pending"
	return job
}

这种写法适合：

纯计算
格式整理
轻量 DTO 转换

好处是边界清楚：调用方不接返回值，就等于没生效。

2. 明确要原地修改，就传指针

1
2
3

func markDone(job *Job) {
	job.Status = "done"
}

这种写法适合：

状态推进
计数累加到某个实体上
生命周期明确的对象修改

好处是副作用直接写在签名里。

3. slice 如果会增长，优先返回新 slice

1
2
3

func addLabel(labels []string, label string) []string {
	return append(labels, label)
}

这种写法比 *[]string 更常见，也更符合 Go 项目里的主流风格。

4. map 如果只是改键值，直接传 map

1
2
3

func recordCount(stats map[string]int, key string) {
	stats[key]++
}

如果要整张替换，就返回新 map：

1
2
3

func resetStats() map[string]int {
	return map[string]int{"failed": 0, "success": 0}
}

十一、几个最常见的副作用坑

这部分建议直接记成排查清单。

1. 以为 struct 按值传了，就彻底隔离了

错误示例：

type Job struct {
	ID     string
	Labels []string
}

func addDefaultLabel(job Job) Job {
	job.Labels = append(job.Labels, "default")
	return job
}

如果调用方原来的 Labels 还有剩余容量，那么这次 append 可能仍然写进共享底层数组。
虽然返回了新 job，但原对象底层数组也可能已经被污染。

更稳的写法是先复制一份：

func addDefaultLabel(job Job) Job {
	labels := append([]string(nil), job.Labels...)
	labels = append(labels, "default")
	job.Labels = labels
	return job
}

2. 以为 slice 传进去之后，`append` 一定能改到外面

错误示例：

1
2
3

func addLine(lines []string, line string) {
	lines = append(lines, line)
}

调用方如果没接返回值，长度变化通常看不到。

3. 以为 map 和空 map 是一回事

错误示例：

1 2	var stats map[string]int stats["failed"]++

这不是“空”，而是“未初始化”。

4. 为了避免拷贝，把所有参数都改成指针

这是另一种常见过度修复。

如果一个函数本来只是读取参数、拼结果，却写成：

1	func buildMessage(job *Job) string

那么调用方会自然怀疑：

这里是不是会改 job
这个参数会不会是 nil
以后是不是到处都得防御性判空

指针不是默认更高级，它只是更明确地引入“共享可变状态”。

十二、先写几个最小测试，把理解固定下来

这类知识点最怕只靠眼睛看打印。
更稳的方式是补几组最小测试。

先看一组示例代码：

package batch

type Job struct {
	ID     string
	Status string
	Labels []string
}

func MarkDone(job Job) {
	job.Status = "done"
}

func MarkDoneInPlace(job *Job) {
	job.Status = "done"
}

func AddLabel(labels []string, label string) []string {
	return append(labels, label)
}

func CloneAndAddLabel(job Job, label string) Job {
	copied := append([]string(nil), job.Labels...)
	copied = append(copied, label)
	job.Labels = copied
	return job
}

测试可以这样写：

package batch

import "testing"

func TestMarkDoneValueDoesNotChangeCaller(t *testing.T) {
	job := Job{ID: "case-001", Status: "pending"}

	MarkDone(job)

	if job.Status != "pending" {
		t.Fatalf("want pending, got %s", job.Status)
	}
}

func TestMarkDonePointerChangesCaller(t *testing.T) {
	job := Job{ID: "case-001", Status: "pending"}

	MarkDoneInPlace(&job)

	if job.Status != "done" {
		t.Fatalf("want done, got %s", job.Status)
	}
}

func TestAddLabelMustUseReturnedSlice(t *testing.T) {
	labels := []string{"smoke"}

	AddLabel(labels, "nightly")

	if len(labels) != 1 {
		t.Fatalf("want len 1, got %d", len(labels))
	}

	labels = AddLabel(labels, "nightly")
	if len(labels) != 2 {
		t.Fatalf("want len 2, got %d", len(labels))
	}
}

func TestCloneAndAddLabelKeepsOriginalUntouched(t *testing.T) {
	job := Job{ID: "case-001", Labels: []string{"smoke"}}

	newJob := CloneAndAddLabel(job, "nightly")

	if len(job.Labels) != 1 {
		t.Fatalf("original labels changed: %v", job.Labels)
	}
	if len(newJob.Labels) != 2 {
		t.Fatalf("new labels not expanded: %v", newJob.Labels)
	}
}

运行：

1	go test ./...

这四个测试覆盖了最核心的四个判断：

值传递不会改调用方 struct
指针会改调用方 struct
slice 增长要接返回值
struct 里带 slice 时，想隔离必须主动复制底层数据

十三、排障时怎么判断自己到底踩的是哪一类坑

项目里看到“数据怎么又串了”，不要先靠感觉猜，先按顺序排。

第一步：先看函数签名

重点看三件事：

参数是 T 还是 *T
参数里有没有 []T、map[K]V
返回值有没有把新结果显式返回出来

很多问题其实函数签名已经暴露了。

第二步：再看操作类型

问自己到底做的是哪种动作：

只是改字段值
改 slice 元素
给 slice append
给 map 写键值
把整个字段重新赋值

不同动作对应的联动方式完全不同。

第三步：必要时打印长度、容量和关键地址

比如查 slice 时，可以先打：

1	fmt.Println(len(labels), cap(labels))

如果确认非空，还可以临时打印首元素地址：

1	fmt.Printf("%p\n", &labels[0])

这能帮助判断两个 slice 当前是不是仍然共用同一块底层数组。

第四步：确认是不是 nil 问题

对 map、pointer、slice 都要有这个意识：

nil map 不能写
nil pointer 不能解引用
nil slice 可以 append，但不能直接按下标赋值

这些错误经常和“值/引用理解错误”混在一起出现。

十四、一个更接近项目现场的小案例

下面用一个更完整的小案例，把这篇的点串起来。

场景：现在要装配一个 nightly 批次：

原始任务模板不能被污染
失败任务要打上 retry 标签
统计计数要实时更新
审计日志要追加

先定义结构：

type Job struct {
	ID     string
	Status string
	Labels []string
}

type Batch struct {
	Name     string
	Jobs     []Job
	Counters map[string]int
	AuditLog []string
}

再定义几类函数：

func NewBatch(name string, jobs []Job) Batch {
	clonedJobs := make([]Job, 0, len(jobs))
	for _, job := range jobs {
		job.Labels = append([]string(nil), job.Labels...)
		clonedJobs = append(clonedJobs, job)
	}

	return Batch{
		Name: name,
		Jobs: clonedJobs,
		Counters: map[string]int{
			"success": 0,
			"failed":  0,
		},
	}
}

func MarkFailed(job *Job) {
	job.Status = "failed"
	job.Labels = append(job.Labels, "retry")
}

func RecordCounter(stats map[string]int, key string) {
	stats[key]++
}

func AddAudit(lines []string, line string) []string {
	return append(lines, line)
}

调用方式：

templates := []Job{
	{ID: "case-001", Status: "pending", Labels: []string{"smoke"}},
	{ID: "case-002", Status: "pending", Labels: []string{"api"}},
}

batch := NewBatch("nightly-20240509", templates)

MarkFailed(&batch.Jobs[0])
RecordCounter(batch.Counters, "failed")
batch.AuditLog = AddAudit(batch.AuditLog, "case-001 marked as failed")

这几行里，每种函数边界都不一样：

NewBatch 返回新值，因为它要保证模板不被污染
MarkFailed 传指针，因为它明确要原地改任务状态
RecordCounter 直接收 map，因为只改已有键值
AddAudit 返回新 slice，因为它会增长切片

这就是工程上更稳的做法：不要只会一种传参方式，而是根据副作用边界选。

十五、工程判断：什么时候该传值，什么时候该传指针

学完语法后最容易走向两个极端：

极端一：坚持所有东西都按值传，结果改状态特别绕
极端二：为了性能或省事，全都传指针

更稳的判断通常是下面这样。

1. 小而清晰的输入对象，优先值传递

例如：

查询参数
配置快照
过滤条件
时间窗口

这类对象如果语义上更像“输入快照”，值传递通常更安全。

2. 明确有生命周期推进的实体，适合指针

例如：

任务状态从 pending 到 running
批次对象持续累积统计
连接对象、缓冲对象需要原地更新

这类对象本来就带状态变化，用指针更直接。

3. 对 slice，重点不是“要不要指针”，而是“会不会增长”

默认先记一个工程规则：

改元素：传 []T 就够
会增长：返回 []T
只有在特别明确的 API 设计里，才考虑 *[]T

4. 对 map，大多数时候不要传 `*map`

因为 map 本身已经能表达“共享一张表”的修改行为。

只有在很少数场景里，比如：

需要懒初始化并替换整个 map
需要把 map 变量本身置为 nil

这时 *map 才可能有讨论空间。

5. 不要为了“性能”先把所有 struct 都改成指针

因为这会同时引入：

nil 风险
共享修改风险
调用方语义不清
测试隔离成本变高

性能优化应该先基于事实，比如基准测试和逃逸分析结果，而不是基于直觉。

十六、边界：这篇先不展开哪些内容

这一篇先解决“值语义、共享底层数据、指针、副作用边界”这条主线。
下面这些内容会在后续文章里再展开：

方法的值接收者和指针接收者如何统一设计
interface 装箱后又会带来哪些复制和动态分派问题
sync.Mutex 为什么不能随便复制
unsafe.Pointer 为什么不适合拿来解释基础语义
逃逸分析和堆栈分配怎么影响性能判断

先把这一篇吃透，比一开始把所有底层细节一起塞进来更重要。

十七、一个实际练习

可以直接把上面的任务执行器再补一版，要求如下：

增加 Retry 字段，失败任务最多重试 2 次
写一个 CloneJob(job Job) Job，要求深拷贝 Labels
写一个 AddJobs(batch Batch, jobs ...Job) Batch，要求返回新批次，不污染原批次
写一个 ResetCounters(stats map[string]int) map[string]int，要求返回新 map
补 4 个测试，分别验证 MarkFailed 会改原任务、CloneJob 不会污染原标签、AddJobs 不会把新任务偷偷写进旧批次的底层数组、ResetCounters 不会影响旧统计表

如果这几个练习能独立写出来，这篇的核心就算真正掌握了。

十八、结语

Go 里关于值类型、引用语义、指针，最重要的不是背术语，而是建立下面这条判断链：

Go 默认一直都在复制值
有些值复制后仍然共享底层数据，所以会表现出引用式行为
slice 的关键在底层数组和切片头分离
map 的关键在共享底层哈希表，但 map 变量本身仍然会被复制
指针不是“特殊传参机制”，而是“把地址这个值传进去”
工程上最重要的是把副作用边界写进函数签名

回头收一下这一篇最该记住的几句话：

不要把“值传递”和“不会共享数据”画等号
不要把“看起来像引用”就误解成“Go 支持按引用传参”
不要为了省事把所有参数都改成指针
只要函数里可能 append，优先返回新 slice
struct 里只要有 slice、map 字段，就要主动考虑深浅复制问题

把这一层写稳，下一篇再看 struct、方法集和组合时，很多“为什么这里能改、那里不能改”的问题就不会再绕住你了。

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

二、先把场景说清楚

三、先看一个最小例子：为什么说 Go 里都是值传递

四、Go 里到底有没有“引用类型”

五、真正的值拷贝到底长什么样

六、struct 是值类型，但里面的字段可能不是“彻底值化”

七、slice 为什么最容易让人误判

八、map 为什么也像引用，但又不该默认传 *map

九、指针到底是什么，它解决了什么问题

十、函数传参到底怎么选，先看语义，不要先看语法

1. 只想基于输入返回新结果，就传值并返回值

2. 明确要原地修改，就传指针

3. slice 如果会增长，优先返回新 slice

4. map 如果只是改键值，直接传 map

十一、几个最常见的副作用坑

1. 以为 struct 按值传了，就彻底隔离了

2. 以为 slice 传进去之后，append 一定能改到外面

3. 以为 map 和空 map 是一回事

4. 为了避免拷贝，把所有参数都改成指针

十二、先写几个最小测试，把理解固定下来

十三、排障时怎么判断自己到底踩的是哪一类坑

第一步：先看函数签名

第二步：再看操作类型

第三步：必要时打印长度、容量和关键地址

第四步：确认是不是 nil 问题

十四、一个更接近项目现场的小案例

十五、工程判断：什么时候该传值，什么时候该传指针

1. 小而清晰的输入对象，优先值传递

2. 明确有生命周期推进的实体，适合指针

3. 对 slice，重点不是“要不要指针”，而是“会不会增长”

4. 对 map，大多数时候不要传 *map

5. 不要为了“性能”先把所有 struct 都改成指针

十六、边界：这篇先不展开哪些内容

十七、一个实际练习

十八、结语

八、map 为什么也像引用，但又不该默认传 `*map`

2. 以为 slice 传进去之后，`append` 一定能改到外面

4. 对 map，大多数时候不要传 `*map`