Appearance
最佳实践
指向 interface 的指针
您几乎不需要指向接口类型的指针。您应该将接口作为值进行传递,在这样的传递过程中,实质上传递的底层数据仍然可以是指针。
接口实质上在底层用两个字段表示:
- 一个指向某些特定类型信息的指针。您可以将其视为"type"。
- 数据指针。如果存储的数据是指针,则直接存储。如果存储的数据是一个值,则存储指向该值的指针。
如果希望接口方法修改基础数据,则必须使用指针传递 (将对象指针赋值给接口变量)。
go
type F interface {
f()
}
type S1 struct{}
func (s S1) f() {}
type S2 struct{}
func (s *S2) f() {}
// f1.f() 无法修改底层数据
// f2.f() 可以修改底层数据,给接口变量 f2 赋值时使用的是对象指针
var f1 F = S1{}
var f2 F = &S2{}
Interface 合理性验证
在编译时验证接口的符合性。这包括:
- 将实现特定接口的导出类型作为接口 API 的一部分进行检查
- 实现同一接口的 (导出和非导出) 类型属于实现类型的集合
- 任何违反接口合理性检查的场景,都会终止编译,并通知给用户
补充:上面 3 条是编译器对接口的检查机制, 大体意思是错误使用接口会在编译期报错。 所以可以利用这个机制让部分问题在编译期暴露。
Bad | Good |
---|---|
go
| go
|
如果 *Handler
与 http.Handler
的接口不匹配, 那么语句 var _ http.Handler = (*Handler)(nil)
将无法编译通过。
赋值的右边应该是断言类型的零值。 对于指针类型(如 *Handler
)、切片和映射,这是 nil
; 对于结构类型,这是空结构。
go
type LogHandler struct {
h http.Handler
log *zap.Logger
}
var _ http.Handler = LogHandler{}
func (h LogHandler) ServeHTTP(
w http.ResponseWriter,
r *http.Request,
) {
// ...
}
接收器 (receiver) 与接口
使用值接收器的方法既可以通过值调用,也可以通过指针调用。
带指针接收器的方法只能通过指针或 addressable values 调用。
例如,
go
type S struct {
data string
}
func (s S) Read() string {
return s.data
}
func (s *S) Write(str string) {
s.data = str
}
sVals := map[int]S{1: {"A"}}
// 你通过值只能调用 Read
sVals[1].Read()
// 这不能编译通过:
// sVals[1].Write("test")
sPtrs := map[int]*S{1: {"A"}}
// 通过指针既可以调用 Read,也可以调用 Write 方法
sPtrs[1].Read()
sPtrs[1].Write("test")
类似的,即使方法有了值接收器,也同样可以用指针接收器来满足接口。
go
type F interface {
f()
}
type S1 struct{}
func (s S1) f() {}
type S2 struct{}
func (s *S2) f() {}
s1Val := S1{}
s1Ptr := &S1{}
s2Val := S2{}
s2Ptr := &S2{}
var i F
i = s1Val
i = s1Ptr
i = s2Ptr
// 下面代码无法通过编译。因为 s2Val 是一个值,而 S2 的 f 方法中没有使用值接收器
// i = s2Val
Effective Go 中有一段关于 pointers vs. values 的精彩讲解。
补充:
- 一个类型可以有值接收器方法集和指针接收器方法集
- 值接收器方法集是指针接收器方法集的子集,反之不是
- 规则
- 值对象只可以使用值接收器方法集
- 指针对象可以使用 值接收器方法集 + 指针接收器方法集
- 接口的匹配 (或者叫实现)
- 类型实现了接口的所有方法,叫匹配
- 具体的讲,要么是类型的值方法集匹配接口,要么是指针方法集匹配接口
具体的匹配分两种:
- 值方法集和接口匹配
- 给接口变量赋值的不管是值还是指针对象,都 ok,因为都包含值方法集
- 指针方法集和接口匹配
- 只能将指针对象赋值给接口变量,因为只有指针方法集和接口匹配
- 如果将值对象赋值给接口变量,会在编译期报错 (会触发接口合理性检查机制)
为啥 i = s2Val 会报错,因为值方法集和接口不匹配。
零值 Mutex 是有效的
零值 sync.Mutex
和 sync.RWMutex
是有效的。所以指向 mutex 的指针基本是不必要的。
Bad | Good |
---|---|
go
| go
|
如果你使用结构体指针,mutex 应该作为结构体的非指针字段。即使该结构体不被导出,也不要直接把 mutex 嵌入到结构体中。
Bad | Good |
---|---|
go
| go
|
| mutex 及其方法是 |
在边界处拷贝 Slices 和 Maps
slices 和 maps 包含了指向底层数据的指针,因此在需要复制它们时要特别注意。
接收 Slices 和 Maps
请记住,当 map 或 slice 作为函数参数传入时,如果您存储了对它们的引用,则用户可以对其进行修改。
Bad | Good |
---|---|
go
| go
|
返回 slices 或 maps
同样,请注意用户对暴露内部状态的 map 或 slice 的修改。
Bad | Good |
---|---|
go
| go
|
使用 defer 释放资源
使用 defer 释放资源,诸如文件和锁。
Bad | Good |
---|---|
go
| go
|
Defer 的开销非常小,只有在您可以证明函数执行时间处于纳秒级的程度时,才应避免这样做。使用 defer 提升可读性是值得的,因为使用它们的成本微不足道。尤其适用于那些不仅仅是简单内存访问的较大的方法,在这些方法中其他计算的资源消耗远超过 defer
。
Channel 的 size 要么是 1,要么是无缓冲的
channel 通常 size 应为 1 或是无缓冲的。默认情况下,channel 是无缓冲的,其 size 为零。任何其他尺寸都必须经过严格的审查。我们需要考虑如何确定大小,考虑是什么阻止了 channel 在高负载下和阻塞写时的写入,以及当这种情况发生时系统逻辑有哪些变化。(翻译解释:按照原文意思是需要界定通道边界,竞态条件,以及逻辑上下文梳理)
Bad | Good |
---|---|
go
| go
|
枚举从 1 开始
在 Go 中引入枚举的标准方法是声明一个自定义类型和一个使用了 iota 的 const 组。由于变量的默认值为 0,因此通常应以非零值开头枚举。
Bad | Good |
---|---|
go
| go
|
在某些情况下,使用零值是有意义的(枚举从零开始),例如,当零值是理想的默认行为时。
go
type LogOutput int
const (
LogToStdout LogOutput = iota
LogToFile
LogToRemote
)
// LogToStdout=0, LogToFile=1, LogToRemote=2
使用 time 处理时间
时间处理很复杂。关于时间的错误假设通常包括以下几点。
- 一天有 24 小时
- 一小时有 60 分钟
- 一周有七天
- 一年 365 天
- 还有更多
例如,1 表示在一个时间点上加上 24 小时并不总是产生一个新的日历日。
因此,在处理时间时始终使用 "time"
包,因为它有助于以更安全、更准确的方式处理这些不正确的假设。
使用 time.Time
表达瞬时时间
在处理时间的瞬间时使用 time.Time
,在比较、添加或减去时间时使用 time.Time
中的方法。
Bad | Good |
---|---|
go
| go
|
使用 time.Duration
表达时间段
在处理时间段时使用 time.Duration
.
Bad | Good |
---|---|
go
| go
|
回到第一个例子,在一个时间瞬间加上 24 小时,我们用于添加时间的方法取决于意图。如果我们想要下一个日历日 (当前天的下一天) 的同一个时间点,我们应该使用 Time.AddDate
。但是,如果我们想保证某一时刻比前一时刻晚 24 小时,我们应该使用 Time.Add
。
go
newDay := t.AddDate(0 /* years */, 0 /* months */, 1 /* days */)
maybeNewDay := t.Add(24 * time.Hour)
对外部系统使用 time.Time
和 time.Duration
尽可能在与外部系统的交互中使用 time.Duration
和 time.Time
例如 :
- Command-line 标志:
flag
通过time.ParseDuration
支持time.Duration
- JSON:
encoding/json
通过其UnmarshalJSON
method 方法支持将time.Time
编码为 RFC 3339 字符串 - SQL:
database/sql
支持将DATETIME
或TIMESTAMP
列转换为time.Time
,如果底层驱动程序支持则返回 - YAML:
gopkg.in/yaml.v2
支持将time.Time
作为 RFC 3339 字符串,并通过time.ParseDuration
支持time.Duration
。
当不能在这些交互中使用 time.Duration
时,请使用 int
或 float64
,并在字段名称中包含单位。
例如,由于 encoding/json
不支持 time.Duration
,因此该单位包含在字段的名称中。
Bad | Good |
---|---|
go
| go
|
当在这些交互中不能使用 time.Time
时,除非达成一致,否则使用 string
和 RFC 3339 中定义的格式时间戳。默认情况下,Time.UnmarshalText
使用此格式,并可通过 time.RFC3339
在 Time.Format
和 time.Parse
中使用。
尽管这在实践中并不成问题,但请记住,"time"
包不支持解析闰秒时间戳(8728),也不在计算中考虑闰秒(15190)。如果您比较两个时间瞬间,则差异将不包括这两个瞬间之间可能发生的闰秒。
Errors
错误类型
声明错误的选项很少。 在选择最适合您的用例的选项之前,请考虑以下事项。
- 调用者是否需要匹配错误以便他们可以处理它? 如果是,我们必须通过声明顶级错误变量或自定义类型来支持
errors.Is
或errors.As
函数。 - 错误消息是否为静态字符串,还是需要上下文信息的动态字符串? 如果是静态字符串,我们可以使用
errors.New
,但对于后者,我们必须使用fmt.Errorf
或自定义错误类型。 - 我们是否正在传递由下游函数返回的新错误? 如果是这样,请参阅错误包装部分。
错误匹配? | 错误消息 | 指导 |
---|---|---|
No | static | errors.New |
No | dynamic | fmt.Errorf |
Yes | static | top-level var with errors.New |
Yes | dynamic | custom error type |
例如, 使用 errors.New
表示带有静态字符串的错误。 如果调用者需要匹配并处理此错误,则将此错误导出为变量以支持将其与 errors.Is
匹配。
无错误匹配 | 错误匹配 |
---|---|
go
| go
|
对于动态字符串的错误, 如果调用者不需要匹配它,则使用 fmt.Errorf
, 如果调用者确实需要匹配它,则自定义 error
。
无错误匹配 | 错误匹配 |
---|---|
go
| go
|
请注意,如果您从包中导出错误变量或类型, 它们将成为包的公共 API 的一部分。
错误包装
如果调用其他方法时出现错误, 通常有三种处理方式可以选择:
- 将原始错误原样返回
- 使用
fmt.Errorf
搭配%w
将错误添加进上下文后返回 - 使用
fmt.Errorf
搭配%v
将错误添加进上下文后返回
如果没有要添加的其他上下文,则按原样返回原始错误。 这将保留原始错误类型和消息。 这非常适合底层错误消息有足够的信息来追踪它来自哪里的错误。
否则,尽可能在错误消息中添加上下文 这样就不会出现诸如“连接被拒绝”之类的模糊错误, 您会收到更多有用的错误,例如“调用服务 foo:连接被拒绝”。
使用 fmt.Errorf
为你的错误添加上下文, 根据调用者是否应该能够匹配和提取根本原因,在 %w
或 %v
动词之间进行选择。
- 如果调用者应该可以访问底层错误,请使用
%w
。 对于大多数包装错误,这是一个很好的默认值, 但请注意,调用者可能会开始依赖此行为。因此,对于包装错误是已知var
或类型的情况,请将其作为函数契约的一部分进行记录和测试。 - 使用
%v
来混淆底层错误。 调用者将无法匹配它,但如果需要,您可以在将来切换到%w
。
在为返回的错误添加上下文时,通过避免使用"failed to"之类的短语来保持上下文简洁,当错误通过堆栈向上渗透时,它会一层一层被堆积起来:
Bad | Good |
---|---|
go
| go
|
|
|
然而,一旦错误被发送到另一个系统,应该清楚消息是一个错误(例如err
标签或日志中的"Failed"前缀)。
另见 不要只检查错误,优雅地处理它们。
错误命名
对于存储为全局变量的错误值, 根据是否导出,使用前缀 Err
或 err
。 请看指南 对于未导出的顶层常量和变量,使用_作为前缀。
go
var (
// 导出以下两个错误,以便此包的用户可以将它们与 errors.Is 进行匹配。
ErrBrokenLink = errors.New("link is broken")
ErrCouldNotOpen = errors.New("could not open")
// 这个错误没有被导出,因为我们不想让它成为我们公共 API 的一部分。 我们可能仍然在带有错误的包内使用它。
errNotFound = errors.New("not found")
)
对于自定义错误类型,请改用后缀 Error
。
go
// 同样,这个错误被导出,以便这个包的用户可以将它与 errors.As 匹配。
type NotFoundError struct {
File string
}
func (e *NotFoundError) Error() string {
return fmt.Sprintf("file %q not found", e.File)
}
// 并且这个错误没有被导出,因为我们不想让它成为公共 API 的一部分。 我们仍然可以在带有 errors.As 的包中使用它。
type resolveError struct {
Path string
}
func (e *resolveError) Error() string {
return fmt.Sprintf("resolve %q", e.Path)
}
处理断言失败
类型断言 将会在检测到不正确的类型时,以单一返回值形式返回 panic。 因此,请始终使用“逗号 ok”习语。
Bad | Good |
---|---|
go
| go
|
不要使用 panic
在生产环境中运行的代码必须避免出现 panic。panic 是 级联失败 的主要根源 。如果发生错误,该函数必须返回错误,并允许调用方决定如何处理它。
Bad | Good |
---|---|
go
| go
|
panic/recover 不是错误处理策略。仅当发生不可恢复的事情(例如:nil 引用)时,程序才必须 panic。程序初始化是一个例外:程序启动时应使程序中止的不良情况可能会引起 panic。
go
var _statusTemplate = template.Must(template.New("name").Parse("_statusHTML"))
即使在测试代码中,也优先使用t.Fatal
或者t.FailNow
而不是 panic 来确保失败被标记。
Bad | Good |
---|---|
go
| go
|
使用 go.uber.org/atomic
使用 sync/atomic 包的原子操作对原始类型 (int32
, int64
等)进行操作,因为很容易忘记使用原子操作来读取或修改变量。
go.uber.org/atomic 通过隐藏基础类型为这些操作增加了类型安全性。此外,它包括一个方便的atomic.Bool
类型。
Bad | Good |
---|---|
go
| go
|
避免可变全局变量
使用选择依赖注入方式避免改变全局变量。 既适用于函数指针又适用于其他值类型
Bad | Good |
---|---|
go
| go
|
go
| go
|
避免在公共结构中嵌入类型
这些嵌入的类型泄漏实现细节、禁止类型演化和模糊的文档。
假设您使用共享的 AbstractList
实现了多种列表类型,请避免在具体的列表实现中嵌入 AbstractList
。 相反,只需手动将方法写入具体的列表,该列表将委托给抽象列表。
go
type AbstractList struct {}
// 添加将实体添加到列表中。
func (l *AbstractList) Add(e Entity) {
// ...
}
// 移除从列表中移除实体。
func (l *AbstractList) Remove(e Entity) {
// ...
}
Bad | Good |
---|---|
go
| go
|
Go 允许 类型嵌入 作为继承和组合之间的折衷。外部类型获取嵌入类型的方法的隐式副本。默认情况下,这些方法委托给嵌入实例的同一方法。
结构还获得与类型同名的字段。 所以,如果嵌入的类型是 public,那么字段是 public。为了保持向后兼容性,外部类型的每个未来版本都必须保留嵌入类型。
很少需要嵌入类型。 这是一种方便,可以帮助您避免编写冗长的委托方法。
即使嵌入兼容的抽象列表 interface,而不是结构体,这将为开发人员提供更大的灵活性来改变未来,但仍然泄露了具体列表使用抽象实现的细节。
Bad | Good |
---|---|
go
| go
|
无论是使用嵌入结构还是嵌入接口,都会限制类型的演化。
- 向嵌入接口添加方法是一个破坏性的改变。
- 从嵌入结构体删除方法是一个破坏性改变。
- 删除嵌入类型是一个破坏性的改变。
- 即使使用满足相同接口的类型替换嵌入类型,也是一个破坏性的改变。
尽管编写这些委托方法是乏味的,但是额外的工作隐藏了实现细节,留下了更多的更改机会,还消除了在文档中发现完整列表接口的间接性操作。
避免使用内置名称
Go 语言规范 概述了几个内置的, 不应在 Go 项目中使用的 预先声明的标识符。
根据上下文的不同,将这些标识符作为名称重复使用, 将在当前作用域(或任何嵌套作用域)中隐藏原始标识符,或者混淆代码。 在最好的情况下,编译器会报错;在最坏的情况下,这样的代码可能会引入潜在的、难以恢复的错误。
Bad | Good |
---|---|
go
| go
|
go
| go
|
注意,编译器在使用预先分隔的标识符时不会生成错误, 但是诸如go vet
之类的工具会正确地指出这些和其他情况下的隐式问题。
主函数退出方式 (Exit)
Go 程序使用 os.Exit
或者 log.Fatal*
立即退出 (使用panic
不是退出程序的好方法,请 不要使用 panic。)
仅在main()
中调用其中一个 os.Exit
或者 log.Fatal*
。所有其他函数应将错误返回到信号失败中。
Bad | Good |
---|---|
go
| go
|
原则上:退出的具有多种功能的程序存在一些问题:
- 不明显的控制流:任何函数都可以退出程序,因此很难对控制流进行推理。
- 难以测试:退出程序的函数也将退出调用它的测试。这使得函数很难测试,并引入了跳过
go test
尚未运行的其他测试的风险。 - 跳过清理:当函数退出程序时,会跳过已经进入
defer
队列里的函数调用。这增加了跳过重要清理任务的风险。