上篇介绍了开发过程中一些常见问题编码规范，下篇主要介绍一些常见问题的更优写法，具体见下图。
1. 指导性原则
1.1 指向 interface 的指针
几乎不需要指向接口类型的指针。应该将接口作为值进行传递，在这样的传递中，实质上传递的底层数据仍然可以是指针。
接口实质上再底层用两个字段表示：
- 一个指向某些特定类型信息的指针，可以将其视为「type」
- 数据指针。如果存储的数据是指针，则直接存储。如果存储的数据是一个值，则存储指向该值的指针。
如果希望接口方法修改基本数据，则必须使用指针传递（将对象指针赋值给接口变量）。
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{}
1.2 interface 合理性验证
在编译时验证接口的符合性。这包括：
- 将实现特定接口的导出类型作为接口 API 的一部分进行检查
- 实现同一接口的（导出和非导出）类型属于实现类型的集合
- 任何违反接口合理性检查的场景，都会终止编译，并通知给用户
注：上面这三条实在是太难理解了，简而言之就是错误使用接口会在编译期报错。所以可以利用这个机制让部分问题在编译器暴露。
Bad:
// 如果Handler没有实现http.Handler,会在运行时报错
type Handler struct {
// ...
}
func (h *Handler) ServeHTTP(
w http.ResponseWriter,
r *http.Request,
) {
...
}
Good：
type Handler struct {
// ...
}
// 用于触发编译期的接口的合理性检查机制
// 如果Handler没有实现http.Handler,会在编译期报错
var _ http.Handler = (*Handler)(nil)
func (h *Handler) ServeHTTP(
w http.ResponseWriter,
r *http.Request,
) {
// ...
}
注：如果 *Handler 与 http.Handler 的接口不匹配，那么语句 var _ http.Handler = (*Handler)(nil) 将无法编译通过。
赋值的右边应该是断言类型的零值。对于指针类型（如 *Handler）、slice 和 map，这是 nil；对于结构类型，这是空结构。
type LogHandler struct {
h http.Handler
log *zap.Logger
}
var _ http.Handler = LogHandler{}
func (h LogHandler) ServeHTTP(
w http.ResponseWriter,
r *http.Request,
) {
// ...
}
1.3 接收器（receiver）与接口
使用值接收器的方法既可以通过值调用，也可以通过指针调用。带指针接收器的方法只能通过指针或 addressable values调用。
例子🌰
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")
类似的，即使方法有了值接收器，也同样可以用指针接收器来满足接口。
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 的精彩讲解。
1.4 零值 Mutex 是有效的
-
零值
sync.Mutex和sync.RWMutex是有效的。所以指向 mutex 的指针基本是不必要的。Bad：
mu := new(sync.Mutex) mu.Lock()Good:
var mu sync.Mutex mu.Lock() -
使用结构体指针，mutex 应该作为结构体的非指针字段。即使该结构不被导出，也不要直接把 mutex 嵌入到结构体中。
Bad：Mutex 字段，Lock 和 Unlock 方法是 SMap 导出的 API 中不刻意说明的一部分。
type SMap struct { sync.Mutex data map[string]string } func NewSMap() *SMap { return &SMap{ data: make(map[string]string), } } func (m *SMap) Get(k string) string { m.Lock() defer m.Unlock() return m.data[k] }Good: mutex 及其方法是 SMap 的实现细节，对其调用者不可见。
type SMap struct { mu sync.Mutex data map[string]string } func NewSMap() *SMap { return &SMap{ data: make(map[string]string), } } func (m *SMap) Get(k string) string { m.mu.Lock() defer m.mu.Unlock() return m.data[k] }注：此条笔者表示存疑。
1.5 在边界处拷贝 Slices 和 Maps
slices 和 maps 包含了指向底层数据的指针，因此在需要复制它们时要特别注意。
-
Slices 和 Maps 做为入参
注意，当 map 或 slice 作为函数参数传入时，如果函数内部存储了对它们的引用，则用户可以对其进行修改。
Bad:
func (d *Driver) SetTrips(trips []Trip) { d.trips = trips } trips := ... d1.SetTrips(trips) // 你是要修改 d1.trips 吗？ trips[0] = ...Good:
func (d *Driver) SetTrips(trips []Trip) { d.trips = make([]Trip, len(trips)) copy(d.trips, trips) } trips := ... d1.SetTrips(trips) // 这里我们修改 trips[0]，但不会影响到 d1.trips trips[0] = ... -
返回 slices 或 maps
注：注意对用户暴露内部状态的 map 或 slice 的修改。
Bad：
type Stats struct { mu sync.Mutex counters map[string]int } // Snapshot 返回当前状态。 func (s *Stats) Snapshot() map[string]int { s.mu.Lock() defer s.mu.Unlock() return s.counters } // snapshot 不再受互斥锁保护 // 因此对 snapshot 的任何访问都将受到数据竞争的影响 // 影响 stats.counters snapshot := stats.Snapshot()Good:
type Stats struct { mu sync.Mutex counters map[string]int } func (s *Stats) Snapshot() map[string]int { s.mu.Lock() defer s.mu.Unlock() result := make(map[string]int, len(s.counters)) for k, v := range s.counters { result[k] = v } return result } // snapshot 现在是一个拷贝 snapshot := stats.Snapshot()
1.6 使用 defer 释放资源
使用 defer 释放资源，诸如文件或锁。
Bad:
p.Lock()
if p.count < 10 {
p.Unlock()
return p.count
}
p.count++
newCount := p.count
p.Unlock()
return newCount
// 当有多个 return 分支时，很容易遗忘 unlock
Good:
p.Lock()
defer p.Unlock()
if p.count < 10 {
return p.count
}
p.count++
return p.count
// 更可读
注：使用 defer 提升可读性是值得的，因为使用它们的成本相比于代码的易读性来说是可以接受的。尤其适用于那些不仅仅是简单内存访问的较大的方法，在这些方法中其他计算的资源消耗远超 defer。
1.7 Channel 的 size 要么是 1，要么是无缓冲的
Channel 通常的 size 应为 1 或是无缓冲的。默认情况下，channel 是无缓冲的，其 size 为零。
Bad:
// 应该足以满足任何情况！
c := make(chan int, 64)
Good:
// 大小：1
c := make(chan int, 1) // 或者
// 无缓冲 channel，大小为 0
c := make(chan int)
注：建议慎重选择 channel 的大小，因为其可能影响竟态条件，以及上下文的逻辑。
1.8 枚举从 1 开始
在 Go 中引入枚举的标准方法是声明一个自定义类型和一个使用了 iota 的 const 组。由于变量的默认值为 0，因此通常应以非零值开头枚举。
Bad:
type Operation int
const (
Add Operation = iota
Subtract
Multiply
)
// Add=0, Subtract=1, Multiply=2
Good:
type Operation int
const (
Add Operation = iota + 1
Subtract
Multiply
)
// Add=1, Subtract=2, Multiply=3
1.9 使用 time 处理时间
时间处理很复杂。关于时间的错误假设通常包括以下几点：
- 一天有 24 小时
- 一小时有 60 分钟
- 一周有七天
- 一年有 365 天
- 还有更多
1.9.1 使用 time.Time 表达瞬时时间
在处理时间的瞬间时使用 time.Time，在比较、添加或减去时间时使用 time.Time 中的方法。
Bad：
func isActive(now, start, stop int) bool {
return start <= now && now < stop
}
Good:
func isActive(now, start, stop time.Time) bool {
return (start.Before(now) || start.Equal(now)) && now.Before(stop)
}
注：用于添加时间的方法取决于意图。如果想要下一个日历日（当前天的下一天）的同一时刻，应该使用
time.AddDate，但是，如果想保证某一个时刻比前一个时刻晚 24 小时，应该使用time.Add。newDay := t.AddDate(0 /* years */, 0 /* months */, 1 /* days */) maybeNewDay := t.Add(24 * time.Hour)
1.9.2 使用 time.Duration 表达时间段
在处理时间段时使用time.Duration。
Bad:
func poll(delay int) {
for {
// ...
time.Sleep(time.Duration(delay) * time.Millisecond)
}
}
poll(10) // 是几秒钟还是几毫秒?
Good:
func poll(delay time.Duration) {
for {
// ...
time.Sleep(delay)
}
}
poll(10*time.Second)
对外部系统使用 time.Time 和 time.Duration
尽可能在与外部系统的交互中使用time.Duration和time.Time。例如：
- Command-line 标志:
flag通过time.ParseDuration支持time.Duration - JSON:
encoding/json通过其UnmarshalJSONmethod 方法支持将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，并在字段名称中包含单位。
Bad：
// {"interval": 2}
type Config struct {
Interval int `json:"interval"`
}
Good:
// {"intervalMillis": 2000}
type Config struct {
IntervalMillis int `json:"intervalMillis"`
}
注1：由于
encoding/json不支持time.Duration，因此该单位包含在字段的名称中。
当在交互中不能使用time.Time 时，除非达成一致，否则使用 string 和 RFC 3339 中定义的格式时间戳。time 包不支持解析闰秒时间戳，也不在计算中考虑闰秒。
1.10 Errors
1.10.1 错误类型
声明错误的选型很少。在使用时，请考虑一下情况：
-
调用者是否需要匹配错误以便他们可以处理它？
如果是，必须通过声明顶级错误便令或自定义类型来支持
errors.Is或errors.As函数。 -
错误消息是否为静态字符串，还是需要上下文信息的动态字符串？
如果是静态字符串，可以使用
errors.New，但是对于动态字符串，必须使用fmt.Errorf或自定义错误类型。 -
是否正在传递由下游函数返回的新错误？
如果是，请参阅后面的错误包装部分。
错误匹配? 错误消息 指导 No static errors.NewNo dynamic fmt.ErrorfYes static top-level varwitherrors.NewYes dynamic custom errortype
errors.New 表示带有静态字符串的错误的例子
无错误匹配:
// package foo
func Open() error {
return errors.New("could not open")
}
// package bar
if err := foo.Open(); err != nil {
// Can't handle the error.
panic("unknown error")
}
错误匹配：
// package foo
var ErrCouldNotOpen = errors.New("could not open")
func Open() error {
return ErrCouldNotOpen
}
// package bar
if err := foo.Open(); err != nil {
if errors.Is(err, foo.ErrCouldNotOpen) {
// handle the error
} else {
panic("unknown error")
}
}
fmt.Errorf 动态字符串的错误的例子🌰
无错误匹配:
// package foo
func Open(file string) error {
return fmt.Errorf("file %q not found", file)
}
// package bar
if err := foo.Open("testfile.txt"); err != nil {
// Can't handle the error.
panic("unknown error")
}
错误匹配：
// package foo
type NotFoundError struct {
File string
}
func (e *NotFoundError) Error() string {
return fmt.Sprintf("file %q not found", e.File)
}
func Open(file string) error {
return &NotFoundError{File: file}
}
// package bar
if err := foo.Open("testfile.txt"); err != nil {
var notFound *NotFoundError
if errors.As(err, ¬Found) {
// handle the error
} else {
panic("unknown error")
}
}
注：从包中导出错误变量或类型，它们将成为包的公共 API 的一部分
1.10.2 错误包装
如果调用失败，有以下几种处理方式：
- 按原样返回原始错误
- 使用
fmt.Errorf和%w - 使用
fmt.Errorf和%v
如果没有要添加的其他上下文，则按原样返回原始错误。否则，尽可能在错误消息中添加上下文，这样就不会出现诸如「连接被拒绝」之类的模糊错误。
使用 fmt.Errorf 添加错误的上下问题，根据调用者的需求，在 %w 或 %v 动词之间进行选择。
- 如果调用者应该可以访问底层错误，请使用
%w。对于大多数包装错误，这是一个很好的默认值。 - 使用
%v来混淆底层错误，调用者无法匹配它，但如果需要，可以在将来改为%w。
注：在返回的错误添加上下文时，通过避免使用「fail to」之类的短语来保持上下文简洁，当错误通过堆栈向上渗透时，它会一层一层被堆积起来：
Bad:
s, err := store.New()
if err != nil {
return fmt.Errorf(
"failed to create new store: %w", err)
}
failed to x: failed to y: failed to create new store: the error
Good:
s, err := store.New()
if err != nil {
return fmt.Errorf(
"new store: %w", err)
}
x: y: new store: the error
注：一旦错误被发送到另一个系统，应该清楚消息是一个错误（例如
err标签或日志中「Failed」前缀 ） 另外不要只检查错误，优雅地处理它们。
1.10.3 错误命名
对于存储为全局变量的错误值，根据是否导出，使用前缀Err 或err.
var (
// 导出以下两个错误，以便此包的用户可以将它们与errors.Is 进行匹配。
ErrBrokenLink = errors.New("link is broken")
ErrCouldNotOpen = errors.New("could not open")
// 这个错误没有被导出，因为我们不想让它成为我们公共 API 的一部分。 我们可能仍然在带有错误的包内使用它。
errNotFound = errors.New("not found")
)
对于自定义错误类型，请改用后缀Error。
// 同样，这个错误被导出，以便这个包的用户可以将它与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)
}
1.11 处理断言失败
类型断言 将会在检测到不正确的类型时，以单一返回值形式返回 panic。 因此，请始终使用「x, ok」的方式。
Bad:
t := i.(string)
Good:
t, ok := i.(string)
if !ok {
// 优雅地处理错误
}
1.12 不要使用 panic
在生成环境中运行的代码必须避免出现 painc。panic 是 级联失败 的主要根源。如果发生错误，该函数必须返回错误，并允许调用方法决定如何处理它。
Bad：
func run(args []string) {
if len(args) == 0 {
panic("an argument is required")
}
// ...
}
func main() {
run(os.Args[1:])
}
Good:
func run(args []string) error {
if len(args) == 0 {
return errors.New("an argument is required")
}
// ...
return nil
}
func main() {
if err := run(os.Args[1:]); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
}
注：panic/recover 不是错误处理策略。仅当发生不可恢复的事情（例如：nil 引用）时，程序才必须 panic。 程序初始化是一个例外：程序启动时应使程序中止的不良情况可能会引起 panic。
即使在测试代码中，也优先使用 t.Fatal 或者t.FailNow 而不是 panic 来确保失败被标记。
Bad:
// func TestFoo(t *testing.T)
f, err := ioutil.TempFile("", "test")
if err != nil {
panic("failed to set up test")
}
Good:
// func TestFoo(t *testing.T)
f, err := ioutil.TempFile("", "test")
if err != nil {
t.Fatal("failed to set up test")
}
1.13 避免可变全局变量
使用选择依赖注入方式避免改变全局变量。即适用于函数指针又适用于其他值类型。
Bad:
// sign.go
var _timeNow = time.Now
func sign(msg string) string {
now := _timeNow()
return signWithTime(msg, now)
}
// sign_test.go
func TestSign(t *testing.T) {
oldTimeNow := _timeNow
_timeNow = func() time.Time {
return someFixedTime
}
defer func() { _timeNow = oldTimeNow }()
assert.Equal(t, want, sign(give))
}
Good:
// sign.go
type signer struct {
now func() time.Time
}
func newSigner() *signer {
return &signer{
now: time.Now,
}
}
func (s *signer) Sign(msg string) string {
now := s.now()
return signWithTime(msg, now)
}
// sign_test.go
func TestSigner(t *testing.T) {
s := newSigner()
s.now = func() time.Time {
return someFixedTime
}
assert.Equal(t, want, s.Sign(give))
}
1.14 避免在公共结构中嵌入类型
假设创建了共享 AbstractList用于实现了多种列表类型，请避免在具体的列表实现中嵌入AbstractList。相反，只需手动将方法写入具体的列表，该列表将委托给抽象列表。
type AbstractList struct {}
// 添加将实体添加到列表中。
func (l *AbstractList) Add(e Entity) {
// ...
}
// 移除从列表中移除实体。
func (l *AbstractList) Remove(e Entity) {
// ...
}
Bad:
// ConcreteList 是一个实体列表。
type ConcreteList struct {
*AbstractList
}
Good:
// ConcreteList 是一个实体列表。
type ConcreteList struct {
list *AbstractList
}
// 添加将实体添加到列表中。
func (l *ConcreteList) Add(e Entity) {
l.list.Add(e)
}
// 移除从列表中移除实体。
func (l *ConcreteList) Remove(e Entity) {
l.list.Remove(e)
}
Go 允许 类型嵌入 作为继承和组合之间的折中。
注：嵌入的结构获得与类型同名的字段。所以，如果嵌入的类型是 public，那么字段是 public。为了保持向后兼容性，外部类型的每个未来版本都必须保留嵌入类型。
很少需要嵌入类型。这是一种方便，可以帮助避免冗长的写法，但其仍然有泄漏具体实现细节的风险。
Bad：
// AbstractList 是各种实体列表的通用实现。
type AbstractList interface {
Add(Entity)
Remove(Entity)
}
// ConcreteList 是一个实体列表。
type ConcreteList struct {
AbstractList
}
Good:
// ConcreteList 是一个实体列表。
type ConcreteList struct {
list AbstractList
}
// 添加将实体添加到列表中。
func (l *ConcreteList) Add(e Entity) {
l.list.Add(e)
}
// 移除从列表中移除实体。
func (l *ConcreteList) Remove(e Entity) {
l.list.Remove(e)
}
无论是嵌入结构还是嵌入接口，都会限制类型的演化。
- 向嵌入接口添加方法是一个破坏性的改变
- 从嵌入结构体删除方法是一个破坏性改变。
- 删除嵌入类型是一个破坏性的改变。
- 即使使用满足相同接口的类型替换嵌入类型，这种操作也是一个破坏性的改变。
注：尽管编写这些委托方法是乏味的，但是隐藏实现细节，留下了更多的更改机会，还消除了在文档中发现完整列表接口的间接性操作。
1.15 避免使用内置名称
Go 语言规范 概述了几个内置的， 不应在Go项目中使用的 预先声明的标识符。
根据上下文的不同，将这些标识符作为名称重复使用，将在当前作用域（或任何嵌套作用域）中隐藏原始标识符，或者混淆代码。在最好的情况下，编译器会报错；在最坏的情况下，这样的代码可能会引入潜在的、难以恢复的错误。
Bad:
var error string
// `error` 作用域隐式覆盖
// or
func handleErrorMessage(error string) {
// `error` 作用域隐式覆盖
}
type Foo struct {
// 虽然这些字段在技术上不构成阴影，但`error`或`string`字符串的重映射现在是不明确的。
error error
string string
}
func (f Foo) Error() error {
// `error` 和 `f.error` 在视觉上是相似的
return f.error
}
func (f Foo) String() string {
// `string` and `f.string` 在视觉上是相似的
return f.string
}
Good:
var errorMessage string
// `error` 指向内置的非覆盖
// or
func handleErrorMessage(msg string) {
// `error` 指向内置的非覆盖
}
type Foo struct {
// `error` and `string` 现在是明确的。
err error
str string
}
func (f Foo) Error() error {
return f.err
}
func (f Foo) String() string {
return f.str
}
注：编译器在使用预先分割的标识符时不会生成错误，但是诸如
go vet之类的工具会正确地之处这些和其他情况下的隐式问题。
1.16 避免使用 init()
尽可能避免使用 init()。当然init() 是不可避免或可取的，代码应该确保：
- 无论程序环境或调用如何，都要完全确定。
- 避免依赖于其他
init()函数的顺序或副作用。虽然init()顺序是明确的，但代码可以更改，因此init()函数之间的关系可能会使代码变得脆弱和容易出错。 - 避免访问或操作全局或环境状态，如机器信息、环境变量、工作目录、程序参数/输入等。
- 避免
I/O，包括文件系统、网络和系统调用。
不能满足这些要求的代码可能属于要作为main()调用的一部分（或程序生命周期中的其他地方），或者作为main() 本身的一部分写入。特别是，打算由其他程序使用的库应该特别注意完全确定性，而不是执行init magic
Bad:
type Foo struct {
// ...
}
var _defaultFoo Foo
func init() {
_defaultFoo = Foo{
// ...
}
}
type Config struct {
// ...
}
var _config Config
func init() {
// Bad: 基于当前目录
cwd, _ := os.Getwd()
// Bad: I/O
raw, _ := ioutil.ReadFile(
path.Join(cwd, "config", "config.yaml"),
)
yaml.Unmarshal(raw, &_config)
}
Good:
var _defaultFoo = Foo{
// ...
}
// or, 为了更好的可测试性:
var _defaultFoo = defaultFoo()
func defaultFoo() Foo {
return Foo{
// ...
}
}
type Config struct {
// ...
}
func loadConfig() Config {
cwd, err := os.Getwd()
// handle err
raw, err := ioutil.ReadFile(
path.Join(cwd, "config", "config.yaml"),
)
// handle err
var config Config
yaml.Unmarshal(raw, &config)
return config
}
考虑到上述情况，在某些情况下，init()可能更可取或是必要的，可能包括：
- 不能表示为单个赋值的复杂表达式
- 可插入的钩子，如
database/sql、编码类型注册表等。 - 对Google Cloud Functions和其他形式的确定性预计算的优化。
1.17 追加时优先指定切片容量
追加优先指定切片容量。在尽可能的情况下，在初始化要追加的切片时为make()提供一个容量值。
Bad：
for n := 0; n < b.N; n++ {
data := make([]int, 0)
for k := 0; k < size; k++{
data = append(data, k)
}
}
BenchmarkBad-4 100000000 2.48s
Good:
for n := 0; n < b.N; n++ {
data := make([]int, 0, size)
for k := 0; k < size; k++{
data = append(data, k)
}
}
BenchmarkGood-4 100000000 0.21s
1.18 主函数退出方式（Exit）
Go 程序使用 os.Exit 或 log.Fatal* 立即退出。仅在main() 中调用前述的其中一个。所有其他函数应将错误返回到信号失败中。
Bad:
func main() {
body := readFile(path)
fmt.Println(body)
}
func readFile(path string) string {
f, err := os.Open(path)
if err != nil {
log.Fatal(err)
}
b, err := ioutil.ReadAll(f)
if err != nil {
log.Fatal(err)
}
return string(b)
}
Good:
func main() {
body, err := readFile(path)
if err != nil {
log.Fatal(err)
}
fmt.Println(body)
}
func readFile(path string) (string, error) {
f, err := os.Open(path)
if err != nil {
return "", err
}
b, err := ioutil.ReadAll(f)
if err != nil {
return "", err
}
return string(b), nil
}
原则上：退出的具有多个出口会存在以下问题：
- 不明显的流程流：任何函数都可以退出程序，因此很难对控制流进行推理。
- 难以测试：退出程序的函数也将退出调用它的测试。这使得函数很难测试，并引入了跳过
go test尚未运行的其他测试的风险。 - 跳过清理：当函数退出程序时，会跳过已经进入
defer队列里的函数调用。这可能会导致重要的清理任务没有被执行
一次性退出
如果可能的话，main()函数中 最多一次 调用os.Exit 或 log.Fatal。如果有多个错误场景停止程序执行，请将该逻辑放在单独的函数下并从中返回错误。
注：这会缩短
main()函数，并将所有关键业务逻辑放入一个单独的、可测试的函数中。
Bad：
package main
func main() {
args := os.Args[1:]
if len(args) != 1 {
log.Fatal("missing file")
}
name := args[0]
f, err := os.Open(name)
if err != nil {
log.Fatal(err)
}
defer f.Close()
// 如果我们调用log.Fatal 在这条线之后
// f.Close 将会被执行.
b, err := ioutil.ReadAll(f)
if err != nil {
log.Fatal(err)
}
// ...
}
Good:
package main
func main() {
if err := run(); err != nil {
log.Fatal(err)
}
}
func run() error {
args := os.Args[1:]
if len(args) != 1 {
return errors.New("missing file")
}
name := args[0]
f, err := os.Open(name)
if err != nil {
return err
}
defer f.Close()
b, err := ioutil.ReadAll(f)
if err != nil {
return err
}
// ...
}
2. 性能
2.1 优先使用 strconv 而不是 fmt
将原语转换我字符串或从字符串转换时，strconv 速度比 fmt 快。
Bad：
for i := 0; i < b.N; i++ {
s := fmt.Sprint(rand.Int())
}
BenchmarkFmtSprint-4 143 ns/op 2 allocs/op
Good:
for i := 0; i < b.N; i++ {
s := strconv.Itoa(rand.Int())
}
BenchmarkStrconv-4 64.2 ns/op 1 allocs/op
2.2 避免字符串到字节的转换
不要反复从固定字符串创建字节 slice。相反，执行一次转换并捕获结果。
Bad：
for i := 0; i < b.N; i++ {
w.Write([]byte("Hello world"))
}
BenchmarkBad-4 50000000 22.2 ns/op
Good:
data := []byte("Hello world")
for i := 0; i < b.N; i++ {
w.Write(data)
}
BenchmarkGood-4 500000000 3.25 ns/op
2.3 指定容器容量
尽可能指定容器容量，以便为容器预先分配内存。这将在添加元素时最小化后续分配（通过复制和调整容器大小）。
2.3.1 指示 Map 容量提示
在尽可能的情况下，在使用 make() 初始化的时候提供容量信息。向 make() 提供容量提示会在初始化时尝试调整 map 的大小，这将减少在将元素添加到 map 时为 map 重新分配内存。
make(map[T1]T2, hint)
注：与 slices 不同。map capacity 提示并不保证完全抢占式分配，而是用于估计所需的 hashmap bucket 的数量。因此，在将元素添加到 map 时，甚至在指定 map 容量时，仍可能发生分配。
**Bad: ** m 是在没有大小提示的情况下创建的，在运行时可能会有更多的分配。
m := make(map[string]os.FileInfo)
files, _ := ioutil.ReadDir("./files")
for _, f := range files {
m[f.Name()] = f
}
Good: m 是有大小提示创建的，在运行时会有更少的分配。
files, _ := ioutil.ReadDir("./files")
m := make(map[string]os.FileInfo, len(files))
for _, f := range files {
m[f.Name()] = f
}
2.3.2 指定切片容量
在尽可能的情况下，在使用make() 初始化切片时提供容量信息，特别是在追加切片时。
make([]T, length, capacity)
注：slice capacity 不是一个提示：编译器将为提供给
make()的 slice 的容量分配足够的内存，这意味着后续的 append() 操作将导致零分配。 在 slice 的长度与容量匹配之后，任何 append 都会调整 slice 大小以容纳其他元素。
Bad:
for n := 0; n < b.N; n++ {
data := make([]int, 0)
for k := 0; k < size; k++{
data = append(data, k)
}
}
BenchmarkBad-4 100000000 2.48s
Good:
for n := 0; n < b.N; n++ {
data := make([]int, 0, size)
for k := 0; k < size; k++{
data = append(data, k)
}
}
BenchmarkGood-4 100000000 0.21s
3. 编程模式
3.1 表驱动测试
当测试逻辑是重复的时候，通过 subtests 使用 table 驱动的方式编写 case 代码看上去会简洁很多。
Bad:
// func TestSplitHostPort(t *testing.T)
host, port, err := net.SplitHostPort("192.0.2.0:8000")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "8000", port)
host, port, err = net.SplitHostPort("192.0.2.0:http")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "http", port)
host, port, err = net.SplitHostPort(":8000")
require.NoError(t, err)
assert.Equal(t, "", host)
assert.Equal(t, "8000", port)
host, port, err = net.SplitHostPort("1:8")
require.NoError(t, err)
assert.Equal(t, "1", host)
assert.Equal(t, "8", port)
Good:
// func TestSplitHostPort(t *testing.T)
tests := []struct{
give string
wantHost string
wantPort string
}{
{
give: "192.0.2.0:8000",
wantHost: "192.0.2.0",
wantPort: "8000",
},
{
give: "192.0.2.0:http",
wantHost: "192.0.2.0",
wantPort: "http",
},
{
give: ":8000",
wantHost: "",
wantPort: "8000",
},
{
give: "1:8",
wantHost: "1",
wantPort: "8",
},
}
for _, tt := range tests {
t.Run(tt.give, func(t *testing.T) {
host, port, err := net.SplitHostPort(tt.give)
require.NoError(t, err)
assert.Equal(t, tt.wantHost, host)
assert.Equal(t, tt.wantPort, port)
})
}
很明显，使用 test table 的方式在代码逻辑扩展的时候，比如新增 test case，都会显得更加清晰。
我们遵循这样的约定：将结构体切片称为 tests。每个测试用例称为 tt 。此外，建议使用 give 和 want 前缀说明每个测试用例的输入和输出值。
tests := []struct{
give string
wantHost string
wantPort string
}{
// ...
}
for _, tt := range tests {
// ...
}
3.2 功能选项
功能选项是一种模式，可以在其中声明一个不透明的 Option 类型，该类型在某些内部结构中记录信息。接受这些选项的编号，并根据内部结构上的选项记录的全部信息采取行动。
将此模式用于扩展构造函数和其他公共 API 中的可选参数，尤其是在这些功能上已经具有三个或更多参数的情况下。
Bad:
// package db
func Open(
addr string,
cache bool,
logger *zap.Logger
) (*Connection, error) {
// ...
}
必须始终提供缓存和记录器参数，即使用户希望使用默认值。
db.Open(addr, db.DefaultCache, zap.NewNop())
db.Open(addr, db.DefaultCache, log)
db.Open(addr, false /* cache */, zap.NewNop())
db.Open(addr, false /* cache */, log)
Good:
// package db
type Option interface {
// ...
}
func WithCache(c bool) Option {
// ...
}
func WithLogger(log *zap.Logger) Option {
// ...
}
// Open creates a connection.
func Open(
addr string,
opts ...Option,
) (*Connection, error) {
// ...
}
只有在需要时才提供选项
db.Open(addr)
db.Open(addr, db.WithLogger(log))
db.Open(addr, db.WithCache(false))
db.Open(
addr,
db.WithCache(false),
db.WithLogger(log),
)
建议实现此模式的方法是使用一个 Option 接口，该接口保存一个未导出的方法，在一个未导出的 options 结构上记录选项。
type options struct {
cache bool
logger *zap.Logger
}
type Option interface {
apply(*options)
}
type cacheOption bool
func (c cacheOption) apply(opts *options) {
opts.cache = bool(c)
}
func WithCache(c bool) Option {
return cacheOption(c)
}
type loggerOption struct {
Log *zap.Logger
}
func (l loggerOption) apply(opts *options) {
opts.logger = l.Log
}
func WithLogger(log *zap.Logger) Option {
return loggerOption{Log: log}
}
// Open creates a connection.
func Open(
addr string,
opts ...Option,
) (*Connection, error) {
options := options{
cache: defaultCache,
logger: zap.NewNop(),
}
for _, o := range opts {
o.apply(&options)
}
// ...
}
注：上面的模式为开发人员提供了更多的灵活性，并且更容易进行调试和测试。特别是，在不可能进行比较的情况下它允许在测试和模拟中对选项进行比较。此外，它还允许选项实现其他接口，包括
fmt.Stringer，允许用户读取选项的字符串表示形式。 还有一种使用闭包实现这个模式的方法。
还可以参考下面的资料：
4. 碎碎念
又是美好的一天吖：
- 我们活着所做的任何事情，都是为了避免痛苦，获得快乐。
- 每天过好自己的生活，就已经很了不起了，不是吗。
- 人世上没有事是有意义的，意义都是人赋予的，而坚持本身就是一个无比闪亮的意义。
