过去几年我花了很多时间看 Go 代码。有时候是为了搞清楚一个库怎么用有时候是面试候选人有时候单纯是想偷点设计灵感。不知不觉看了几百个项目——有 GitHub 上几十个 star 的练手作品也有每天处理百万请求的生产系统。看得多了我发现一件很有意思的事这些项目差距很大但犯的错几乎一模一样。不管你项目是火还是不火有些坑它就是会反复出现。下面是让我印象最深的几个。1. 所有人都搞了一个“万能工具箱”每个项目都会出现一个叫utils的包起初只是放了一个小工具函数。三个月后它变成了一个“什么东西都能塞”的垃圾桶——字符串处理、JSON 解析、认证、日志、数据库连接……全在里面。project/ utils/ string.go json.go auth.go logger.go db.go这不是“整理”这是“懒得整理”。好的 Go 项目是用“职责”来组织代码的而不是用“方便”。2. 接口先写“以防万一”Go 的接口是隐式实现的——这是它的优点之一。但很多人反而把这优点浪费了代码还没写接口已经定义好了。typeUserServiceinterface{GetUser(idstring)(*User,error)}看起来“面向未来”实际上只是把简单的事情搞复杂了。好项目的接口通常是“消费者”定义的——谁要用谁定接口。生产者只管提供功能不管抽象。3. Context 成了“隐形垃圾桶”context.Context的设计目的是传递超时、取消信号和请求级别的元数据。但有些项目把它当成了“传家宝”——数据库连接、配置对象、缓存实例、日志器……全往里塞。Request | v -------- | DB | | Cache | | Logger | | Config | --------这导致函数签名很好看但你在调用它之前永远不知道它真正需要什么。如果依赖重要请显式传递。4. 同一个错误被记了四遍我见过一个很经典的日志习惯函数 A 记一遍错误再返回调用方 B 记一遍API 处理器 C 记一遍最后中间件 D 再记一遍。一个数据库超时日志里出现了四条一模一样的条目。错误日志应该在错误最终被处理的地方记录而不是在每层路过的地方都写一遍。Go 的错误包装已经给了你传递上下文的工具别滥用日志。5. 包之间互相“串门”有些项目表面上分了包实际上还是一整坨代码。业务逻辑 import HTTP 处理器数据库模型 import REST 响应对象工具包 import 业务服务——依赖图跟蜘蛛网一样。API ---- Service ^ | | v DB ---- Utils健康项目的依赖方向应该是明确的底层包提供能力高层包组合它们。依赖关系要“单向”不要“互相缠绕”。6. 配置读得到处都是配置一开始很简单一个环境变量。然后两个。然后开始有配置文件。然后命令行参数也加进来了。然后每个包都开始自己读配置——改个配置都不知道源头在哪里。好项目会有一个统一的配置层负责加载、校验、分发配置。其他地方只接收不读取。7. goroutine 不要钱但也不能随便开Go 的 goroutine 是轻量但不是无限。我见过循环里直接开几千个 goroutine 的代码for_,job:rangejobs{goprocess(job)}本地跑没问题一上生产就炸——内存飙升、外部 API 被打爆、数据库连接池耗尽。好的并发设计不是“开更多 goroutine”而是控制并发数量——用 worker pool、信号量或者有界管道。8. 测试测的是实现不是行为很多项目测试覆盖率很高但真正让人放心的测试很少。大量测试在验证私有函数、mock 了几乎所有依赖、一重构就碎一地。好测试像用户故事不关心“内部怎么实现的”只关心“对外表现对不对”。好测试能扛住重构因为它测的是行为不是代码行。9. 把简单的事搞复杂了有些项目看起来像在 Go 里重建了一套 Java 企业级架构工厂模式创建 BuilderBuilder 生成 RepositoryRepository 被 Service 包装Service 又被 Manager 包裹最后通过一个 DI 容器初始化。就为了做一个小型 CRUD 应用。Go 鼓励的做事方式不一样构造函数返回结构体结构体上挂方法方法解决问题。这个模式往往能用很久。不是所有东西都需要三层抽象有时候一个直白的函数比一个“可扩展的架构”更好用。让我印象深刻的那些项目看了这么多之后我发现最好的项目从来不是最“花哨”的。它们没有玩高级的语言特性没有堆砌设计模式也没有试图用架构震撼别人。它们只是有一些共同点文件小到一次能看完依赖方向是单向的接口只在真的有多个实现时才出现并发是有意控制的不是随手写的错误有上下文但日志不吵每个包都有“存在的理由”读这些项目不像解谜更像读一本写得很清楚的书——你知道下次应该去哪找东西因为结构反映的是问题本身而不是某种框架或设计模式。Go 的“简洁”常常被误解。它不是“不费劲”而是做了上百个小决定来减少复杂性——这就是好代码和普通代码的区别。花哨的语言特性用一次少一次但“让代码保持简单”这个习惯会一直跟着你。