RussellLuo

如果你对AI编程助手感兴趣，一定听说过Claude Code。遗憾的是，由于网络环境和账号限制，国内用户直接使用它非常困难。目前比较流行的方案是借助Claude Code Router，但经过笔者测试，配置并成功用起来仍有一定门槛。

作为Vibe Coding玩家，笔者尝试实现了一个简易版本的替代方案 —— Claude Code Mate，不仅能让你用上Claude Code，还能自由切换其他主流大模型。

有意思的是，Claude Code Mate项目本身的大部分代码，也是Vibe Coding的产物（由Claude Code生成）。

Claude Code Mate

项目地址：https://github.com/RussellLuo/claude-code-mate

Claude Code Mate（以下简称CCM）是一个专门为Claude Code设计的辅助工具，通过内置的LiteLLM Proxy，让你可以灵活接入多种大模型。它的最大特点是安装便捷、配置简单，适合不想折腾的开发者用户。

CCM能做什么

1. 无障碍使用Claude Code

   无需直接注册Anthropic账号，只需配置一个第三方API Key（例如通过OpenRouter平台获取），即可在国内网络环境下稳定使用Claude Code。

2. 一键切换多种模型

   除了Claude系列模型，你还可以方便地切换到Gemini、DeepSeek、GPT等其他大模型。只需在配置文件中简单设置，就能按需选用不同模型。

3. 比同类方案更便捷

   其他流行方案如Claude Code Router（CCR）也能实现类似功能，但由于CCR有Router（路由器）和Transformer（转换器）等功能，导致理解和配置较复杂。相比之下，CCM只聚焦于切换不同的模型和提供商，并将所有功能打包成一条命令，安装后简单设置就能使用。

快速开始

以OpenRouter为例，只需几步即可完成：

1
2
3
4
5
6
7
8
9
10
11
12

pip install claude-code-mate

# 启动LiteLLM Proxy
export OPENROUTER_API_KEY=your-api-key
ccm start

# 设置环境变量（按`ccm start`的输出指示）
export ANTHROPIC_BASE_URL=http://0.0.0.0:4000
export ANTHROPIC_AUTH_TOKEN=sk-xxx

# 现在可以正常使用Claude Code了
claude --model claude-3.5-haiku

总结

Claude Code Mate的优势在于开箱即用和配置简便，特别适合以下用户：

• 想用Claude Code但受限于网络环境的国内用户
• 希望尝试不同大模型并集中管理配置
• 喜欢简洁方案，不想花费太多时间进行其他定制

如果你正在寻找一个简单有效的方式使用Claude Code和切换各种大模型，不妨试试Claude Code Mate这个工具。

一、更新 John 的数据

假设我们有一条关于 John 的数据如下：

1
2
3
4
5
6
7
8
9
10
11

GET /people/1 HTTP/1.1

{
    "name": "John",    
    "age": 20,
    "address": {
        "country": "China",
        "province": "Guangdong",
        "city": "Shenzhen",
    }
}

现在我们想更新他的年龄和所在城市，于是发起了一个请求：

1
2
3
4
5
6
7
8

PATCH /people/1 HTTP/1.1

{
    "age": 25,
    "address": {
        "city": "Guangzhou",
    }
}

作为 Go 服务端开发人员，我们如何才能正确处理这个部分更新请求呢？

二、Go 零值与 JSON

乍一看并不难，我们立马写下了结构体定义：

1
2
3
4
5
6
7
8
9
10
11

type Address struct {
	Country  string `json:"country"`
	Province string `json:"province"`
	City     string `json:"city"`
}

type Person struct {
	Name    string  `json:"name"`
	Age     int     `json:"age"`
	Address Address `json:"address"`
}

JSON 反序列化？自然也不在话下：

1
2
3
4

blob := []byte(`{"age": 25, "address": {"city": "Guangzhou"}}`)
var person Person
_ = json.Unmarshal(blob, &person)
fmt.Printf("person: %+v\n", person)

对应的输出结果（Go Playground）：

1

person: {Name: Age:25 Address:{Country: Province: City:Guangzhou}}

很显然，如果我们直接用 person 去更新 John 的数据，他的姓名、所在国家和省份都会被清空！

那服务端该如何正确识别客户端的原始意图呢？具体到 John 的例子，在 Go 中如何做到 “只更新他的年龄和所在城市” 呢？

三、业界通用解法

据我所知，对于上述问题，业界通常有以下三种解法。

使用指针

因为 Go 的零值特性，普通类型无法表达 “未初始化” 的状态，典型解法就是使用指针。

采用指针后，上面的结构体定义将变成：

1
2
3
4
5
6
7
8
9
10
11

type Address struct {
	Country  *string `json:"country"`
	Province *string `json:"province"`
	City     *string `json:"city"`
}

type Person struct {
	Name    *string  `json:"name"`
	Age     *int     `json:"age"`
	Address *Address `json:"address"`
}

再次进行 JSON 反序列化：

1
2
3
4

blob := []byte(`{"age": 25, "address": {"city": "Guangzhou"}}`)
var person Person
_ = json.Unmarshal(blob, &person)
fmt.Printf("person: %+v, address: %+v\n", person, person.Address)

对应的输出结果（Go Playground）：

1

person: {Name:<nil> Age:0xc000018218 Address:0xc00000c138}, address: &{Country:<nil> Province:<nil> City:0xc0000103f0}

可以看到只有 Age 和 Address.City 的值不为 nil，于是我们只需要更新不为 nil 的字段即可：

1
2
3
4
5
6
7
8
9
10
11

func (a *Address) Update(other *Address) {
	if other.Country != nil {
		a.Country = other.Country
	}
	if other.Province != nil {
		a.Province = other.Province
	}
	if other.City != nil {
		a.City = other.City
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func (p *Person) Update(other *Person) {
	if other.Name != nil {
		p.Name = other.Name
	}
	if other.Age != nil {
		p.Age = other.Age
	}
	if other.Address != nil {
		// Side effects of using pointers
		if p.Address == nil {
			p.Address = new(Address)
		}
		p.Address.Update(other.Address)
	}
}

参考完整代码（Go Playground）不难发现，使用指针后的 Person 结构体，操作起来会非常繁琐。比如：

• 修改 address 前，需要首先保证 p.Address 不能为 nil
• 此外，Initialization 初始化操作尤其麻烦

客户端维护的 FieldMask

受 Protocol Buffers 设计的影响，另一种较为流行的做法是在请求中新增一个 FieldMask 参数，用来补充说明需要更新的字段名称。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

type Address struct {
	Country  string `json:"country"`
	Province string `json:"province"`
	City     string `json:"city"`
}

type Person struct {
	Name    string  `json:"name"`
	Age     int     `json:"age"`
	Address Address `json:"address"`
}

type UpdatePersonRequest struct {
	Person    Person `json:"person"`
	FieldMask string `json:"field_mask"`
}

1
2
3
4

blob := []byte(`{"person": {"age": 25, "address": {"city": "Guangzhou"}}, "field_mask": "age,address.city"}`)
var req UpdatePersonRequest
_ = json.Unmarshal(blob, &req)
fmt.Printf("req: %+v\n", req)

对应的输出结果（Go Playground）：

1

req: {Person:{Name: Age:25 Address:{Country: Province: City:Guangzhou}} FieldMask:age,address.city}

有了 FieldMask 的补充说明，服务端就能正确进行部分更新了。但是对于客户端而言，FieldMask 其实是多余的，而且维护成本也不低（特别是待更新字段较多时），这也是我认为该方案最明显的一个不足之处。

改用 JSON Patch

前面讨论的方案，本质上都是 JSON Merge Patch 风格的。部分更新还有另外一个比较有名的风格，那就是 JSON Patch。

具体到 John 的例子，部分更新请求变成了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

PATCH /people/1 HTTP/1.1

[
    { 
        "op": "replace", 
        "path": "/age", 
        "value": 25
    },
    {
        "op": "replace",
        "path": "/address/city",
        "value": "Guangzhou"
    }
]

相比于前面的解法而言，该解法的主要缺点是 PATCH 请求体跟待更新文档的 JSON 数据格式差异太大，表达上不太符合直觉。

四、服务端维护的 FieldMask

如果我们坚持 JSON Merge Patch 风格的部分更新，综合来看「客户端维护的 FieldMask」是相对较好的方案。那有没有可能进一步规避该方案的不足，即不增加客户端的维护成本呢？经过一段时间的研究和思考，我认为答案是肯定的。

有经验的读者可能会发现，Go 的 JSON 反序列化其实有两种：

• 将 JSON 反序列化为结构体（优势：操作直观方便；不足：有零值问题）
• 将 JSON 反序列化为 map[string]interface{}（优势：能够准确表达 JSON 中有无特定字段；不足：操作不够直观方便）

可想而知，如果我们直接把 Person 从结构体改为 map[string]interface{}，操作体验可能会比使用带指针的结构体更糟糕！

那如果我们只是把 map[string]interface{} 作为一个反序列化的中间结果呢？比如：

1. 首先将 JSON 反序列化为 map[string]interface{}
2. 然后用 map[string]interface{} 来充当（服务端维护的）FieldMask
3. 最后将 map[string]interface{} 解析为结构体（幸运的是，已经有现成的库 mapstructure 可以做到！）

通过一些探索和试验，结果表明上述想法是可行的。为此，我还专门开发了一个小巧的库 fieldmask，用来辅助实现基于该想法的部分更新。

具体到 John 的例子，借助 fieldmask 库，结构体可以定义成最自然的方式（不需要使用指针）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

type Address struct {
	Country  string `json:"country"`
	Province string `json:"province"`
	City     string `json:"city"`
}

type Person struct {
	Name    string  `json:"name"`
	Age     int     `json:"age"`
	Address Address `json:"address"`
}

type UpdatePersonRequest struct {
	Person
	FieldMask fieldmask.FieldMask `json:"-"`
}

func (req *UpdatePersonRequest) UnmarshalJSON(b []byte) error {
	if err := json.Unmarshal(b, &req.FieldMask); err != nil {
		return err
	}
	return mapstructure.Decode(req.FieldMask, &req.Person)
}

注意，其中 JSON 反序列化的核心代码是 UnmarshalJSON。对应的更新逻辑如下（完整示例）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func (a *Address) Update(other Address, fm fieldmask.FieldMask) {
	if len(fm) == 0 {
		// Clear the entire address.
		*a = other
		return
	}

	if fm.Has("country") {
		a.Country = other.Country
	}
	if fm.Has("province") {
		a.Province = other.Province
	}
	if fm.Has("city") {
		a.City = other.City
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func (p *Person) Update(other Person, fm fieldmask.FieldMask) {
	if len(fm) == 0 {
		// Clear the entire person.
		*p = other
		return
	}

	if fm.Has("name") {
		p.Name = other.Name
	}
	if fm.Has("age") {
		p.Age = other.Age
	}
	if addressFM, ok := fm.FieldMask("address"); ok {
		p.Address.Update(other.Address, addressFM)
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

john := Person{
	Name: "John",
	Age:  20,
	Address: Address{
		Country:  "China",
		Province: "Guangdong",
		City:     "Shenzhen",
	},
}

blob := []byte(`{"age": 25, "address": {"city": "Guangzhou"}}`)
req := new(UpdatePersonRequest)
_ = json.Unmarshal(blob, req)

john.Update(req.Person, req.FieldMask)

个人觉得，相比其他方案而言，上述代码实现非常简单、自然（如果还有优化空间，欢迎指正👏🏻）。

当然该方案也不是完美的，目前来说，我认为至少有一个瑕疵就是需要两次解码：JSON -> map[string]interface{} -> 结构体，会增加一点性能上的开销。

五、相关阅读

• Go, REST APIs, and Pointers
• Practical API Design at Netflix, Part 2: Protobuf FieldMask for Mutation Operations
• REST: Partial updates with PATCH

一、缘起

1. 背景：系统重构选型 Go kit

为什么不直接使用 Web 框架（如 Gin）?

根据旧系统使用 Flask 的经验，稍具规模、多人协作的工程代码，如果没有严格的分层约束，很容易做成一锅蛋炒饭（我们应该做盖浇饭）。

旧系统的常见问题：

• HTTP 层和业务层，常常傻傻分不清楚（导致测试业务层代码，需要模拟 HTTP 请求）；
• HTTP/DB 层的细节，常常会混入业务层（比如业务层在处理 Flask 或者 SQLAlchemy 的数据结构）；
• 没有使用依赖注入，单元测试必须借助 Mock 工具（比如 Python 的 unittest.mock）。

为什么不使用 Go micro?

• Go micro 作为一套微服务开发框架，复杂度较高，可控度不够；
• 新系统一开始的定位是 “优雅（模块化）的大单体”（备注），所以选择了更灵活的 Go kit。

备注：Microservice Architecture at Medium（Medium 的微服务架构 ）。

It is fine to start with a monolithic architecture, but make sure to modularize it and architect it with the above three microservice principles (single purpose, loose coupling and high cohesion), except that the “services” are implemented in the same tech stack, deployed together and run in the same process.

选择 Go kit 意味着什么?

• 成熟的分层思想：整洁架构（意义指数：★★★）
• 优雅的错误处理：如何将业务层 error 转换为 HTTP 状态码（意义指数：★★☆）
• 灵活的协议切换：同时支持 HTTP 和 gRPC（意义指数：★★☆）

2. 问题：手写代码太繁琐

Go kit 核心代码分为三层：

• Transport（繁琐指数：★★★）
• Endpoint（繁琐指数：★★★）
• Service（繁琐指数：☆☆☆）

业界吐槽：
Why I Recommend to Avoid Using the go-kit Library。

3. 为什么要造轮子？

Go kit 列举的 两款工具：

• kujtimiihoxha/kit（缺点：不再维护）
• metaverse/truss（缺点：需要手写 Protocol Buffers）

一言以蔽之：已有的轮子不简洁、不好用。

二、设计

1. 初衷

Kun 最初的定位：一款 HTTP 代码生成工具，让大家专注于 Service 层代码（业务逻辑），无需手写 Transport 层和 Endpoint 层代码。

Kun 可以生成的代码包括：

• Endpoint 层代码
• Transport 层代码
  • HTTP server
  • HTTP client
  • HTTP test
  • OAS 文档

2. 哲学

• 聚焦最有价值的事
  • 别再折腾 Web 框架了，专注于你的业务价值！
• 尽量只写 Go 代码
  • 用 Go（而不是其他 DSL）来描述你的服务定义。
• 可维护性很重要
  • 拥抱整洁架构（核心是思想本质，而不是条条框框）。

3. 原理

参考 How it works。

4. 注解

为什么要用注解？

备注：「直接注解」的可维护性高于「YAML 文件」，源自 Where to configure transcoding。

Two mechanisms are supported for doing this: direct annotations in your .proto file, and in YAML as part of your gRPC API configuration file. We recommend using proto annotations for ease of reading and maintenance.

注解设计

语法借鉴：

• OpenAPI Specification
• Google HTTP annotations
• Go comment directives

设计考量：

1. 越典型的场景越简洁
   • 最典型的 JSON API 只需写一行 //kun:op；
   • 支持自动绑定 URL 中的 Path 参数；
   • Query 也是常用的 HTTP 参数，所以 //kun:param 中默认 in=query，同时 //kun:body 中指定 - 可以让所有参数从 Body 切换绑定到 Query；
   • HTTP 参数名称默认为 snake case（下划线风格），也支持切换到 lower camel case（驼峰风格）；
   • 200 是最常用的成功响应状态码，所以是 //kun:success 中默认 statusCode=200。
2. 复杂的场景也能支持
   • 需要使用 Query、Header、Cookie 参数时，可以用 //kun:param 来指定；
   • 支持参数聚合：将多个 HTTP 参数绑定到一个 Method 参数上；
   • 复杂请求和响应的编解码，可以通过自己实现 HTTP Codec 来达成。
3. 服务接口完全由业务决定
   • Go interface 中每个 Method 的入参和出参，不强求一定要定义成结构体，可以从业务出发使用最自然的签名。

三、展望

Kun 未来的定位：不仅仅局限于一款 Go kit 的代码生成工具，而是成为一款通用的 Go 服务通信工具 —— 致力于处理 Go 服务之间的通信，让开发者专注于业务价值。

Kun 对服务通信的约定：

1. 服务通信应该依赖于抽象接口，而不是具体类型；
   • 服务之间只依赖 Go interface；
   • 当前 Kun 生成的 HTTP client 代码也实现了服务定义的 Go interface。
2. 基于约定 1，服务通信的类型应该是可以灵活切换的。
   • 最终 Kun 可能会支持的通信类型：
     • 进程内函数调用；
     • RPC（比如 HTTP 和 gRPC）；
     • 异步消息（尚不支持）。

一、自动化测试的重要性

公理：要正确交付软件代码，测试是必不可少的。

1. 测试分类

• 手动测试
• 自动化测试

2. 何时采用何种测试？

• 一次性使用的代码
  • 示例：临时脚本或工具
  • 采用手工测试
• 需要维护的代码
  • 示例：业务代码
    • 警惕陷阱：这个需求后面不会改，先手动测试吧
  • 采用自动化测试
    • 手工测试低效、重复、乏味
    • 自动化测试可以充当代码变更的保护网

二、测试金字塔

1. 核心原则

• 编写不同粒度的测试
• 层次越高，编写的测试应该越少

2. 反模式

• 测试冰淇淋

三、单元测试

1. Why

为什么要多写单元测试？

• 规模小（关注点聚焦，更容易编写）
• 执行快（最小化依赖，运行成本低）

2. What

何为一个单元？

• 面向过程/函数式：一个函数
• 面向对象：一个方法、一个类

群居和独居

• 独居：隔离所有外部依赖
• 群居：只隔离那些执行慢或者副作用大的依赖（比如数据库、外部服务等）

3. How

测试什么？

• 通常只测试一个类的公共方法
• 如果一个类复杂到需要测试它的私有方法
  • 考虑从设计上拆分这个类，把这些私有方法变成另一个类的公共方法

测试结构（Arrange-Act-Assert 或者 Given-When-Then）

• 准备测试数据
• 调用被测方法
• 断言返回的是期待的结果

四、集成测试

测试应用和所有外部依赖的集成。

常见的外部依赖有：

• 数据库（如 MySQL、Redis、Elasticsearch）
• 消息队列（如 Kafka）
• 外部服务（如 SendCloud、S3)
  • 进行契约测试
    • 编写消费方测试
    • 同时为外部服务编写提供方测试？
      • 通常不需要。因为成熟的服务提供方往往会对 API 做版本控制；而且在废弃旧版本 API 之前，也会通知到服务消费方。

五、契约测试

1. 不适用场景

公共服务的提供方和消费方之间。

2. 适用场景

内部微服务的提供方和消费方之间。

提供方和消费方之间的通信方式，常见的有：

• RPC 接口
  • HTTP/JSON
  • gRPC
• 异步事件

3. 契约测试的特征

• 消费方编写消费方测试，并生成一个协议文件（Pact 的 JSON 示例）
• 提供方根据协议文件，编写提供方测试

六、UI 测试

前后端分离的架构下，UI 测试可以是：

• 纯前端 UI 测试
• 后端 API 集成测试（cURL 和 Postman 测试的自动化版本）

七、避免重复测试

1. 测试成本

• 编写和维护测试要花时间
• 阅读和理解他人的测试也要花时间
• 执行这些测试也要花时间

2. 基本法则

• 如果一个更高层级的测试发现了一个错误，并且底层测试全都通过了，那么应该编写一个低层级测试去覆盖这个错误
• 竭尽所能把测试往金字塔下层赶
• 删掉那些已经被低层级测试覆盖完全的高层级测试
  • 警惕陷阱：沉没成本（不忍删除花了时间精力编写的测试）

八、相关阅读

• 测试金字塔实战（英文版）
• Why bother writing tests at all?
• Introducing the Software Testing Cupcake (Anti-Pattern)

一、由 iter 包引发的疑问

最近在 GitHub 上偶然发现了 Brad Fitzpatrick 的 iter 包，整个包只有 一个函数（一行代码）：

1
2
3

func N(n int) []struct{} {
	return make([]struct{}, n)
}

但其中的一行注释令人费解：

It does not cause any allocations.

1. 空结构体

我们知道，struct{} 是空结构体（empty struct）。关于空结构体，Dave Cheney 在 The empty struct 中作了很好地阐述：

• 空结构体不占用空间（The empty struct consumes no storage）。
• 空结构体的切片只占用切片头的空间（Slices of struct{}s consume only the space for their slice header）。

2. Go 切片

按照官方博客 Go Slices: usage and internals 的说法：

A slice is a descriptor of an array segment. It consists of a pointer to the array, the length of the segment, and its capacity (the maximum length of the segment).

因为切片总是指向一个底层数组的，所以所谓的 “切片头” 其实就是切片本身。一个切片包括：指向数组片段的指针、数组片段的长度和最大长度，总共 3 个字长（在 64 位机器上，就是 24 个字节）。

3. 疑问

按照上面的分析，在 64 位机器上，不管 n 是多少，make([]struct{}, n) 得到的切片一定会占用 24 个字节，reddit 上的讨论 也证实了我们的分析。

那为什么 Brad Fitzpatrick 声称函数 N 不会引发分配呢？

为了解决这个疑惑，我们需要先弄清楚两个问题：

1. 一个 Go 变量可能会被分配在哪里？
2. 如何确定一个 Go 变量最终会被分配在哪里？

二、Go 变量可能的分配位置

1. 进程的内存布局

在 Linux/x86-32 系统中，一个进程的典型的内存布局如下图所示（图片来自 The Linux Programming Interface 图 6-1）：

结合维基百科对 Data segment 的描述，我们得知：

• 初始化的全局变量或静态变量，会被分配在 Data 段。
• 未初始化的全局变量或静态变量，会被分配在 BSS 段。
• 在函数中定义的局部变量，会被分配在堆（Heap 段）或栈（Stack 段）。
  • 实际上，如果考虑到 编译器优化，局部变量还可能会被 分配在寄存器，或者直接被 优化去掉。

2. Go 内存分配

对于 Go 而言，有两个地方可以用于分配：

• 堆（heap）
  • 由 GC 负责回收。
  • 对应于进程地址空间的堆。
• 栈（stack）
  • 不涉及 GC 操作。
  • 每个 goroutine 都有自己的栈，初始时被分配在进程地址空间的栈上，扩容时被分配在进程地址空间的堆上。

Go 变量主要分为两种：

• 全局变量
  • 会被 Go 编译器标记为一些特殊的 符号类型，分配在堆上还是栈上目前尚不清楚，不过不是本文讨论的重点。
• 局部变量

所以综上，对于在函数中定义的 Go 局部变量：要么被分配在堆上，要么被分配在栈上。

三、确定 Go 变量最终的分配位置

至此，我们还剩下一个问题：对于一个 Go 局部变量，如何确定它被分配在堆上还是栈上？

按照官方 FAQ How do I know whether a variable is allocated on the heap or the stack? 的解释：

• Go 编译器会尽可能将变量分配在栈上
• 以下两种情况，Go 编译器会将变量分配在堆上
  • 如果一个变量被取地址（has its address taken），并且被逃逸分析（escape analysis）识别为 “逃逸到堆”（escapes to heap）
  • 如果一个变量很大（very large）

1. 逃逸分析

以使用 iter 包的这段代码为例：

1
2
3
4
5
6
7

package main

import "github.com/bradfitz/iter"

func main() {
        for range iter.N(4) {}
}

下列演示中，我将使用 Go 1.11.4：

1
2

$ go version
go version go1.11.4 darwin/amd64

下面我们对这段代码作逃逸分析：

1
2
3
4
5
6

$ go build -gcflags='-m -m' examples/go_mem/main.go
# command-line-arguments
examples/go_mem/main.go:5:6: cannot inline main: unhandled op RANGE
examples/go_mem/main.go:6:18: inlining call to iter.N func(int) []struct {} { return make([]struct {}, iter.n) }
examples/go_mem/main.go:6:18: make([]struct {}, iter.n) escapes to heap
examples/go_mem/main.go:6:18: 	from make([]struct {}, iter.n) (non-constant size) at ./main.go:6:18

按照前面的分析，从 “make([]struct {}, iter.n) escapes to heap” 的信息，我们推断：make([]struct {}, iter.n) 会被分配在堆上。

到这里，我们最初的疑惑似乎已经有了答案：make([]struct {}, iter.n) 一定会引发堆分配，那是 Brad Fitzpatrick 的注释写错了吗？

2. 内存分配器追踪

除了逃逸分析，Go 还提供了一种叫内存分配器追踪（Memory Allocator Trace）的方法，用于细粒度地分析由程序引发的所有堆分配（和释放）操作：

1

$ GODEBUG=allocfreetrace=1 go run examples/go_mem/main.go 2>&1 | grep -C 10 examples/go_mem

因为进行内存分配器追踪时，很多由 runtime 引发的分配信息也会被打印出来，所以我们用 grep 进行过滤，只显示由用户代码（user code）引发的分配信息。然而这里的输出结果为空，表明 make([]struct {}, iter.n) 没有引发任何堆分配。

内存分配器追踪的结论与逃逸分析的结论截然相反！那到底哪个结论是对的呢？

3. 汇编分析

黔驴技穷之际，Go’s Memory Allocator - Overview 这篇文章给了我提示：

So, we know that i is going to be allocated on the heap. But how does the runtime set that up? With the compiler’s help! We can get an idea from reading the generated assembly.

关于 Go 汇编（assembly），推荐大家阅读 Go internals, Chapter 1: Go assembly。

下面我们来看看示例代码对应的汇编：

1
2
3
4
5
6
7
8
9

$ go tool compile -I $GOPATH/pkg/darwin_amd64 -S examples/go_mem/main.go
...
0x001d 00029 (examples/go_mem/main.go:6)        LEAQ    type.struct {}(SB), AX
0x0024 00036 (examples/go_mem/main.go:6)        PCDATA  $2, $0
0x0024 00036 (examples/go_mem/main.go:6)        MOVQ    AX, (SP)
0x0028 00040 (examples/go_mem/main.go:6)        MOVQ    $4, 8(SP)
0x0031 00049 (examples/go_mem/main.go:6)        MOVQ    $4, 16(SP)
0x003a 00058 (examples/go_mem/main.go:6)        CALL    runtime.makeslice(SB)
...

可以看到，其中有一处对 runtime.makeslice(SB) 的调用，显然是由 make([]struct{}, n) 引发的。

查看 runtime.makeslice 的源码：

1
2
3
4
5

func makeslice(et *_type, len, cap int) slice {
	...
	p := mallocgc(et.size*uintptr(cap), et, true)
	return slice{p, len, cap}
}

其中，mallocgc 的源码如下：

1
2
3
4
5
6
7
8
9
10
11

func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
	...
	if size == 0 {
		return unsafe.Pointer(&zerobase)
	}
	...
	if debug.allocfreetrace != 0 {
		tracealloc(x, size, typ)
	}
	...
}

slice 对应的结构体如下：

1
2
3
4
5

type slice struct {
	array unsafe.Pointer
	len   int
	cap   int
}

结合上述几段源码，我们可以看出：

• makeslice 函数中：slice 结构体正是我们在第一节提到的 Go 切片 —— array 是指向数组片段的指针，len 是数组片段的长度，cap 是数组片段的最大长度。
• makeslice 函数中：array 的值来自 p，而 p 则是一个指针，它指向由 mallocgc 分配得到的底层数组。
• mallocgc 函数中：因为空结构体的 size 为 0，所以 mallocgc 并没有实际进行堆分配；由于没有执行到 tracealloc 的地方，所以进行内存分配器追踪时，不会采集到相关的分配信息。
• makeslice 函数中：切片 slice 本身是以结构体的形式返回的，所以只会被分配在栈上。

四、总结

经过一系列的探索和分析，至此，我们可以得出以下结论：

• make([]struct{}, n) 只会被分配在栈上，而不会被分配在堆上。
• Brad Fitzpatrick 的注释是对的，并且他的意思是 “不会引发堆分配”。
• 逃逸分析识别出 escapes to heap，并不一定就是堆分配，也可能是栈分配。
• 进行内存分配器追踪时，如果采集不到堆分配信息，那一定只有栈分配。

最后，我们来解答文章标题提出的疑问 —— 如何确定一个 Go 变量会被分配在哪里？对此，我们的答案是：

1. 先对代码作逃逸分析。
   • 如果该变量被识别为 escapes to heap，那么它十有八九是被分配在堆上。
   • 如果该变量被识别为 does not escape，或者没有与之相关的分析结果，那么它一定是被分配在栈上。
2. 如果对 escapes to heap 心存疑惑，就对代码作内存分配器追踪。
   • 如果有采集到与该变量相关的分配信息，那么它一定是被分配在堆上。
   • 否则，该变量一定是被分配在栈上。
3. 此外，如果想知道 Go 编译器是如何将变量分配在堆上或者栈上的，可以去分析 Go 汇编（以及 runtime 源码）。

五、思考题

• 如果换成 make([]int, n)，结果还会是栈分配吗？
• 如果换成 make([]int, 4) 呢？
• 除了空结构体 make([]struct{}, n) 的特例，还有哪些 “被逃逸分析识别为 escapes to heap，但其实是栈分配” 的案例？
• Go 支持闭包（closure），那么闭包中的变量，又是分配在哪里的？（Where are variables in a closure stored - stack or heap? 说是分配在栈上，对于 Go 也是成立的吗？）

六、相关阅读

• The empty struct
• Go Slices: usage and internals
• Escape analysis
• Go’s Memory Allocator - Overview
• Go internals, Chapter 1: Go assembly
• Five things that make Go fast