Go 生态选型速查

它解决什么问题

Go 的第三方库生态极其庞大，但真正写进生产代码的往往很少——因为标准库的质量已经高到「够用就不引依赖」成为社区共识。问题在于，这个共识需要逐场景判断：net/http 能不能扛住当前流量？database/sql 算不算 ORM？服务间通信该上 gRPC 还是 REST？每个判断都依赖经验，而经验散落在各个项目的踩坑记录里。

这个技能把这些判断固化成一套可复用的决策流程：给定一个 Go 技术选型问题，它会先定位所属的任务域（Web、数据库访问、服务间通信、并发、日志配置测试、CLI），再按「规模优先」的原则给出建议，而不是丢给你一份按 Stars 排序的列表。

核心能力与关键步骤

场景到选型的映射是它的主干。几个值得注意的判断口径：

• Web 服务：简单 API 或内部服务直接上标准库 net/http（1.22+ 已支持方法与通配符路由）；只有需要中间件生态或团队熟悉度时，才选社区最主流的一两个轻量框架；极端 QPS 场景要先压测标准库，确认瓶颈后再考虑高性能替代。
• 数据库访问：按团队 SQL 熟练度分流。SQL 熟练、查询复杂 → database/sql + 轻量映射扩展；CRUD 密集 → 主流 ORM，并接受其学习成本与 SQL 可控性损失；想要类型安全又不想放弃 SQL → 代码生成方案。
• 服务间通信：判断标准只有一条——调用方是谁。内部机器对机器用 gRPC（Protobuf 契约即文档），面向人/浏览器/第三方用 REST + OpenAPI。
• 并发：原语一律标准库（goroutine/channel/sync），明确反对引入「并发框架」这类抽象。
• 日志与配置：新项目默认 slog（1.21+ 已内置结构化日志）；简单配置用环境变量，多环境多来源再上配置库。

第三方库评估清单是另一个核心。引入任何依赖前必须检查：最近 6 个月有无提交和 issue 响应（比星标数重要）、API 是否稳定（v1 以上？breaking change 频繁吗）、go mod graph 拉进了多少间接依赖、许可证是否可商用、能否包一层防腐层接口以便未来替换。它的底层假设是「每个依赖都是负债」——供应链风险与升级成本是真实存在的。

反模式警示则承担纠偏作用：把其他语言的「依赖注入容器」「全家桶框架」习惯搬进 Go、两人团队按大厂架构拆八个微服务、用反射魔法库换取几行代码的节省，都属于它明确标记的禁区。

适用边界与注意点

它给的是评估方法，不是永久答案。Go 生态演进很快，具体库的活跃度必须以检索当日数据为准——清单里的「最近 6 个月有无提交」这一项，本身就要求执行时重新验证。

另一个边界在于规模前提。「先问规模再选型」意味着所有建议都附带了适用场景：单体小服务与百微服务集群的选型完全不同，技能不会替你做这个判断，但它会强迫你把规模说清楚。选型还需结合团队现有技能与存量系统，架构决策建议留下 ADR（决策记录）备查，以便日后复盘当时为什么这么选。