Go 的设计哲学：让无聊成为一种美德

第一次用 Go 写后端服务时，我觉得它太啰嗦了——错误要一个个手动处理，没有继承，接口不需要显式声明，连泛型也迟来了十几年。但用久了之后，我开始觉得这些「限制」其实是刻意的选择，而且选得很准。

Go 不是一门让你写出「精妙代码」的语言，它是一门让你写出「可以放心交给任何人维护」的代码的语言。这两件事差得很远。

接口：定义权在消费方，不在提供方

这是 Go 里我觉得最被低估的设计。Go 的接口是隐式实现的——一个类型只要有对应的方法，不需要显式 implements，就自动满足接口。

但更重要的是另一个惯例：接口应该在使用它的包里定义，而不是在实现它的包里。

// 在 service 包，定义「这个 service 需要什么」
type UserStore interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
}
 
// 具体的数据库实现在另一个包，完全不知道这个接口的存在
// 只要方法签名匹配，就自动满足

这一条反转了通常的依赖方向：提供方不决定接口，消费方决定。消费方只声明自己需要的最小能力，提供方自然就可以被任意替换——测试时换成 mock，换数据库时换成新的实现，Service 层的代码一行不动。

这和「面向接口编程」是同一件事，但 Go 的隐式实现让你更容易做到「接口尽量小」，因为你只会声明自己真正需要的那一两个方法，而不是继承一个大而全的抽象基类。

零值即可用：好的设计不需要初始化仪式

Go 鼓励类型的零值就能直接用。sync.Mutex、bytes.Buffer、sync.WaitGroup 都是这样——声明出来就能工作，不需要 New() 或 init()。

var mu sync.Mutex
mu.Lock()   // 直接用，没问题
 
var buf bytes.Buffer
buf.WriteString("hello")  // 同样，声明即可用

这不只是语法便利，背后是一个设计约束：你在设计类型时，要想清楚零状态代表什么语义，并让它有意义。一个常见的反例是 map——Go 的 nil map 可以读（返回零值），但不能写（会 panic）。所以含有 map 字段的结构体必须在构造时初始化，否则调用方会踩坑。

「零值即可用」倒逼你思考：这个类型的初始状态是什么？它有没有意义？

错误是值，不是例外

Go 没有 try/catch。函数返回 (result, error) 二元组，调用方必须显式处理。最初觉得烦，后来发现这是一个很好的设计压力：调用方永远清楚「这个操作可能失败」，不能假装例外不存在。

Go 1.13 之后，错误包装成了标准做法：

func LoadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("load config %s: %w", path, err)
    }
    // ...
}

%w 包装错误，调用方可以用 errors.Is 和 errors.As 解包到原始错误类型，同时保留了完整的调用链上下文。错误信息读起来像一条路径：load config /etc/app.yaml: open /etc/app.yaml: no such file or directory——出了什么事、在哪一层出的，一目了然。

并发：不要共享内存，通过通信来共享

Go 的 goroutine 和 channel 设计背后有一句口号：「不要通过共享内存来通信，而要通过通信来共享内存。」实践中这意味着，优先用 channel 在 goroutine 之间传递数据所有权，而不是用锁保护共享状态。

一个容易被忽视的问题是 goroutine 泄漏——goroutine 启动了，但没有退出机制：

// 有问题：没有接收方时，goroutine 永远阻塞在发送上
func leakyFetch(url string) <-chan []byte {
    ch := make(chan []byte)
    go func() {
        data, _ := fetch(url)
        ch <- data  // 如果没人读，这里永远卡住
    }()
    return ch
}
 
// 修正：用带缓冲的 channel + context 取消
func safeFetch(ctx context.Context, url string) <-chan []byte {
    ch := make(chan []byte, 1)
    go func() {
        data, err := fetch(url)
        if err != nil {
            return
        }
        select {
        case ch <- data:
        case <-ctx.Done():
        }
    }()
    return ch
}

context 是 Go 并发代码里的统一取消信号——每个可能长时间运行或等待外部资源的操作，第一个参数都应该是 ctx context.Context，并且在适当的地方响应它。

简单是一种选择，不是妥协

Go 在某些地方的选择初看很保守：没有操作符重载，没有隐式类型转换，gofmt 强制统一格式，错误处理显式而繁琐。但正是这些「限制」，让一个十人团队的代码库和一个人写的代码库读起来没有太大的风格差异——任何人接手都能快速上手，而不需要先解码原作者的「个人风格」。

写 Go 时，我给自己的标准是：这段代码能不能被三个月后的自己一眼看懂？如果不能，说明写复杂了。

一句话心法

无聊的代码是最好的代码——可预测、易维护、任何人都能改，这是工程里最难得的品质。