Program-Language on Sang's Blog

理解编程语言中的闭包设计

Fri, 09 May 2025 19:43:07 +0800

1. 什么是闭包

所谓的闭包，其实就是存储了函数及其关联环境的一个实体，使其在脱离上下文时照常运行。

从字面上理解，闭包就是将函数封闭、打包（中华文化博大精深，闭包这两个字明显比 Closure 更加贴切）

封闭指的是：封闭外部状态，即内部环境无法访问到外部状态，或者说外部状态无法对内部产生影响

打包指的是：为了能够脱离外部环境而存在，要将需要用到的外部环境打包到自己的内部空间

我认为许多人在理解闭包时，仅仅理解到了闭包能够扩展变量的作用域这一层面，而忽略了闭包的封闭性（或者说是隔离性），

2. 如何获得闭包

通俗地说，获得闭包的方式就是将函数作为值返回

3. 闭包和对象 / 函数的区别

首先应该明确的是：闭包既非对象，也不是函数或作用域

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment).¹

闭包是捆绑在一起（封闭）的函数与对其周围状态（词法环境）的引用的组合。

闭包应该是一个组合，在中英文 wiki 中分别被解释成了“结构体”和“记录”，但都不应该简单地将其理解为对象或者函数。

闭包与对象和函数的联系应该是：闭包相当于一个带状态的函数，闭包相当于只有一个函数的对象。²

并且实际上对象系统能够基于闭包实现。³

4. 参考

Go Module 管理和 Toolchain 配置

Wed, 08 May 2024 15:16:00 +0800

1. 核心规则回顾

go 指令
- 表示模块的 最低语言版本兼容性（代码必须能在该版本运行）。
- 影响：语言特性、标准库行为、模块解析规则等。
toolchain 指令
- 建议使用的工具链版本（编译器/链接器），但 不强制（除非显式配置或版本不满足要求）。
- 影响：编译器优化、构建速度、生成的二进制质量等。
工具链选择优先级（Go 1.21+）：
- 如果当前 Go 版本 ≥ toolchain 版本 → 直接使用当前版本。
- 如果当前 Go 版本 < toolchain 版本 → 尝试下载或切换到指定工具链（需满足 GOTOOLCHAIN 配置）。

2. 场景分类与分析

2.1 项目与依赖的 `go` 版本相同，`toolchain` 不同

示例：

1
2
3
4
5
6
7


// 你的项目
go 1.22.0
toolchain go1.22.6 // 显式指定

// 依赖包
go 1.22.0
toolchain go1.23.1

行为：
- 你的项目用 go1.22.6 编译，依赖包的 toolchain go1.23.1 会被忽略（因为 1.22.6 < 1.23.1 但未强制切换）。
- 风险：依赖包可能依赖 1.23.1 的优化，但实际未生效。

2.2 项目的 `go` 版本 > 依赖的 `go` 版本

示例：

1
2
3
4
5
6


// 你的项目
go 1.23.0

// 依赖包
go 1.21.0
toolchain go1.22.0

行为：
- 依赖包的 toolchain go1.22.0 会被忽略（因为你的工具链 1.23.0 > 1.22.0）。
- 优势：高版本 Go 通常兼容低版本模块。

2.3 项目的 `go` 版本 < 依赖的 `go` 版本（危险！）

示例：

1
2
3
4
5
6


// 你的项目
go 1.21.0

// 依赖包
go 1.22.0
toolchain go1.23.1

行为：
- 编译报错！因为你的项目要求 Go 1.21.0，但依赖包需要 ≥1.22.0。
- 解决方案：升级项目的 go 版本或降低依赖包版本。

2.4 依赖包未指定 `toolchain`

示例：

1
2
3
4
5
6


// 你的项目
go 1.22.0
toolchain go1.22.6

// 依赖包
go 1.22.0 // 无 toolchain

行为：
- 依赖包默认使用与 go 指令相同的工具链（即假设 toolchain go1.22.0）。
- 你的项目仍用 go1.22.6 编译（因为 1.22.6 > 1.22.0）。

2.5 显式强制工具链切换（通过 `GOTOOLCHAIN`）

环境变量：

1

export GOTOOLCHAIN=go1.23.1+auto # 自动下载缺失版本

行为：
- 即使当前版本是 go1.22.6，也会强制切换到 go1.23.1 编译。
- 适用场景：需要严格匹配依赖包的工具链建议时。

3. 特殊场景与边界情况

3.1 依赖包的 `toolchain` 版本 < 项目的 `go` 版本

示例：

1
2
3
4
5
6
7


// 你的项目
go 1.23.0
toolchain go1.23.1

// 依赖包
go 1.22.0
toolchain go1.22.0

行为：
- 依赖包的 toolchain go1.22.0 会被忽略（因为 1.23.1 > 1.22.0）。
- 仍用 go1.23.1 编译。

3.2 跨主版本兼容性问题（如 Go1 → Go2）

规则：
- Go 1.x 无法编译依赖 Go 2.x 的模块（未来可能需要显式升级）。
- 目前 Go 2 尚未发布，但设计上会通过 go.mod 的 go 指令隔离。

3.3 工具链自动下载（Go 1.21+）

条件：
- 当前 Go 版本 < 依赖包的 toolchain 版本。
- GOTOOLCHAIN 设置为 auto 或 latest。
行为：
- 自动下载并切换到指定工具链（如 go1.23.1）。

4. 决策流程图

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


开始编译
│
├─ 检查项目的 go 和 toolchain 版本
│ ├─ 若 toolchain 指定且当前版本不满足 → 尝试切换或下载
│ └─ 否则使用当前版本
│
├─ 检查所有依赖包的 go 和 toolchain 版本
│ ├─ 若依赖包的 go 版本 > 项目的 go 版本 → 报错
│ ├─ 若依赖包的 toolchain 版本 > 当前版本 → 根据 GOTOOLCHAIN 决定是否切换
│ └─ 否则忽略依赖包的 toolchain
│
└─ 使用最终确定的工具链版本编译

5. 最佳实践建议

保持 go 版本与依赖包一致
- 避免因版本差异导致隐式问题（如 go 1.22.0 的项目依赖 go 1.21.0 的包是安全的，反之则危险）。
谨慎使用 toolchain 指令
- 仅在需要特定工具链优化或修复时使用，避免过度约束。
利用 GOTOOLCHAIN 控制环境
- 在 CI/CD 中设置 GOTOOLCHAIN=latest+auto 确保一致性。
定期检查依赖包的版本声明
- 使用 go list -m all 查看依赖树，确保无版本冲突。

6. 总结

能编译成功的组合：项目的 go 版本 ≥ 依赖包的 go 版本。
工具链的影响：仅当依赖包的 toolchain > 当前版本且配置允许时才会切换。
最危险场景：项目的 go 版本 < 依赖包的 go 版本（直接报错）。

为结构体内的接口实现 json 反序列化

Fri, 24 Sep 2021 13:55:01 +0800

1. 背景

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


type AData struct {
 A string `json:"a"`
}

type BData struct {
 B string `json:"b"`
}

type Message struct {
 Name string `json:"name"`
 Id int `json:"id"`
 Data interface{} `json:"data"`
}

对于 interface 类型的数据很容易实现序列化(不需要任何额外步骤)

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


msgA := Message{
 Name: "msg_a",
 Id: 1,
 Data: AData{
 A: "a_data",
 },
}
msgB := Message{
 Name: "msg_b",
 Id: 2,
 Data: BData{
 B: "b_data",
 },
}

msgAJ, _ := json.Marshal(msgA)
log.Info("A", zap.Reflect("msgA", msgA), zap.ByteString("msgAJ", msgAJ))

msgBJ, _ := json.Marshal(msgB)
log.Info("B", zap.Reflect("msgB", msgB), zap.ByteString("msgBJ", msgBJ))

但 interface 反序列化后会变成 map[string]interface 类型，想要转成 struct 只能使用 mapstructure 之类的库

1
2
3
4


var msgX Message
_ = json.Unmarshal(msgAJ, &msgX)
log.Info("X", zap.Reflect("msgX", msgX), zap.Reflect("msgX.Data.A", msgX.Data.(AData).A))
// panic: interface conversion: interface {} is map[string]interface {}, not main.AData

此处是无法直接用 msgX.Data.A 来访问的，同样的 msgX.Data.(AData).A 也是不行的，因为这时候的 data 已经被反序列化成了 map[string]interface

1.1 解决方法 1

解决方法也很简单，只要再反序列化时能够知道需要反序列化成的类型即可。

在解析的时候定义临时 struct 继承 Message 并重新定义 Data 的类型。

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


msgXA := struct {
 *Message
 Data AData `json:"data"`
}{}
_ = json.Unmarshal(msgAJ, &msgXA)
log.Info("XA", zap.Reflect("msgXA", msgXA), zap.Reflect("msgXA.Data.A", msgXA.Data.A))

msgXB := struct {
 *Message
 Data BData `json:"data"`
}{}
_ = json.Unmarshal(msgBJ, &msgXB)
log.Info("XB", zap.Reflect("msgXB", msgXB), zap.Reflect("msgXB.Data.B", msgXB.Data.B))

1.2 解决方法 2

另一种思路是拆分 struct 每次序列化时将其合并，反序列化时再将其拆分¹²

缺点是每次需要传送两个变量

 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


type ShortMessage struct {
 Name string `json:"name"`
 Id int `json:"id"`
}

func TestJsonStructSplit(t *testing.T) {
 msgA := ShortMessage{
 Name: "msg_a",
 Id: 1,
 }
 dataA := AData{
 A: "a_data",
 }

 msgB := ShortMessage{
 Name: "msg_b",
 Id: 2,
 }
 dataB := BData{
 B: "b_data",
 }

 // marshal

 msgAJ, _ := json.Marshal(struct {
 *ShortMessage
 *AData
 }{&msgA, &dataA})

 msgBJ, _ := json.Marshal(struct {
 *ShortMessage
 *BData
 }{&msgB, &dataB})

 // unmarshal

 var msgXA ShortMessage
 var dataXA AData
 _ = json.Unmarshal(msgAJ, &struct {
 *ShortMessage
 *AData
 }{&msgXA, &dataXA})

 var msgXB ShortMessage
 var dataXB BData
 _ = json.Unmarshal(msgBJ, &struct {
 *ShortMessage
 *BData
 }{&msgXB, &dataXB})
}

1.3 解决方法 3

只在反序列化时拆分¹²

缺点是 Data 实际上被解析了两次（一次解析成了 map，另一次解析成了 struct），而且每次使用时候还必须进行类型转换

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


var msgXA Message
var dataXA AData
_ = json.Unmarshal(msgAJ, &struct {
 *Message
 *AData `json:"data"`
}{&msgXA, &dataXA})
msgXA.Data = dataXA
t.Log("msgXA", msgXA, "data", msgXA.Data.(AData).A)

var msgXB Message
var dataXB BData
_ = json.Unmarshal(msgBJ, &struct {
 *Message
 *BData `json:"data"`
}{&msgXB, &dataXB})
msgXB.Data = dataXB
t.Log("msgXB", msgXB, "data", msgXB.Data.(BData).B)

2. 完整测试代码

 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
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141


package main

import (
 "encoding/json"
 "testing"
)

type AData struct {
 A string `json:"a"`
}

type BData struct {
 B string `json:"b"`
}

type Message struct {
 Name string `json:"name"`
 Id int `json:"id"`
 Data interface{} `json:"data"`
}

var msgA = Message{
 Name: "msg_a",
 Id: 1,
 Data: AData{
 A: "a_data",
 },
}

var msgB = Message{
 Name: "msg_b",
 Id: 2,
 Data: BData{
 B: "b_data",
 },
}

func TestJsonStruct(t *testing.T) {
 // marshal

 msgAJ, _ := json.Marshal(msgA)
 msgBJ, _ := json.Marshal(msgB)

 // unmarshal

 msgXA := struct {
 *Message
 Data AData `json:"data"`
 }{}
 _ = json.Unmarshal(msgAJ, &msgXA)
 t.Log("msgXA", msgXA, "data", msgXA.Data.A)

 msgXB := struct {
 *Message
 Data BData `json:"data"`
 }{}
 _ = json.Unmarshal(msgBJ, &msgXB)
 t.Log("msgXB", msgXB, "data", msgXB.Data.B)
}

type ShortMessage struct {
 Name string `json:"name"`
 Id int `json:"id"`
}

var msgAS = ShortMessage{
 Name: "msg_as",
 Id: 1,
}

var dataA = AData{
 A: "a_data",
}

var msgBS = ShortMessage{
 Name: "msg_bs",
 Id: 2,
}

var dataB = BData{
 B: "b_data",
}

func TestJsonStructSplit(t *testing.T) {
 // marshal

 msgAJ, _ := json.Marshal(struct {
 *ShortMessage
 *AData
 }{&msgAS, &dataA})

 msgBJ, _ := json.Marshal(struct {
 *ShortMessage
 *BData
 }{&msgBS, &dataB})

 // unmarshal

 var msgXA ShortMessage
 var dataXA AData
 _ = json.Unmarshal(msgAJ, &struct {
 *ShortMessage
 *AData
 }{&msgXA, &dataXA})
 t.Log("msgXA", msgXA, "data", dataXA.A)

 var msgXB ShortMessage
 var dataXB BData
 _ = json.Unmarshal(msgBJ, &struct {
 *ShortMessage
 *BData
 }{&msgXB, &dataXB})
 t.Log("msgXB", msgXB, "data", dataXB.B)
}

func TestJsonStructFull(t *testing.T) {
 // marshal

 msgAJ, _ := json.Marshal(msgA)
 msgBJ, _ := json.Marshal(msgB)

 // unmarshal

 var msgXA Message
 var dataXA AData
 _ = json.Unmarshal(msgAJ, &struct {
 *Message
 *AData `json:"data"`
 }{&msgXA, &dataXA})
 msgXA.Data = dataXA
 t.Log("msgXA", msgXA, "data", msgXA.Data.(AData).A)

 var msgXB Message
 var dataXB BData
 _ = json.Unmarshal(msgBJ, &struct {
 *Message
 *BData `json:"data"`
 }{&msgXB, &dataXB})
 msgXB.Data = dataXB
 t.Log("msgXB", msgXB, "data", msgXB.Data.(BData).B)
}

3. 参考

defer 和 return 的执行顺序陷阱

Fri, 28 Aug 2020 16:08:25 +0800

Golang 中 defer 几乎被当作 try catch final 使用，但事实上 defer 对返回值的修改和 final 仍然有些一些微妙的不同

1. 问题的产生

先来看一段简短的代码

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


// defer.go
func deferTest() string {
 s := "init"
 defer func() {
 s = "defer"
 }()
 return s
}

func main() {
 fmt.Println(deferTest())
}

我们知道 defer 会在 return 之前以先进后出的顺序执行，但是 deferTest() 返回的是 init 还是 defer 呢。

运行结果：

1
2


> go run defer.go
init

很显然，程序在 return 前会先执行 s = "defer" 然后再 return。

但是打印的结果却是 init。

是 defer 没有被执行吗？是 defer 晚于 return 执行吗？并不是，这里先不解释，稍微修改一下代码重新执行

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


// defer.go
func deferTest() (s string) {
 s = "init"
 defer func() {
 s = "defer"
 }()
 return s
}

func main() {
 fmt.Println(deferTest())
}

1
2


> go run defer.go
defer

这个时候返回结果变成 defer 了，我们仅仅是给返回值加上了命名，defer 就将返回值改变了。

2. 解释

实际上，return 前确实会先执行 defer 的内容，但是返回值却不是任何时候都会在 defer 时被改变的。

return 的执行顺序应该是这样的：

给 返回值 赋值
调用 RET 指令，并传入 返回值
- RET 先检查是否存在 defer，存在则逆序执行
- RET 携带 返回值 退出函数

这里的第一步，若是匿名返回值，那么在给 返回值 赋值时，将会先声明一个 返回值 (因为没有定义返回值的名称)

1

返回值 := s

若是命名的返回值，则直接赋值（因为已经声明过了）

1

s = s

这样，最后匿名返回值返回的是 返回值，而命名为 s 的返回值则返回 s 的值。

这也是为什么命名返回值之后可以直接 return 的原因，因为执行 return s 其实也就只是约等于多执行了一条没有意义的 s = s 而已，和 return 是一样的。

或者不严谨的说：golang 中 func function() returnType {} 的 returnType 其实并不像其他语言一样代表的是“返回值类型”，而是一个“匿名返回值”才对。