Go 是一种强大的语言，以其简洁、快速和并发模型而著称。但 Go 社区素来反对框架和集中式惯例——而这正是许多团队，特别是那些来自 Rails、Django 或 FastAPI 等结构化环境的团队，遇到挫折的地方。

这篇帖子探讨了 Go 开发中的结构上的缺口，为何存在这一缺口，以及 Encore 如何通过一个约定驱动的框架来填补这一空缺，为后端开发带来清晰性、一致性和更高的生产效率。

没有明确的风格指南，尽管存在一种可识别的“Go 风格”。

— Go 官方网站 FAQ

自始至终，Go 就被设计为避免大型框架常带来的复杂性问题。Go 的设计者故意省略了许多东西——项目结构、路由、迁移、后台处理等方面，从而给开发者更多的自由和灵活性。

这种理念确实带来了实实在在的好处。Go的简洁性使其易于学习。Go中的并发机制（goroutines和channels）既优雅又高效。其标准库高效而完善。

但正如许多团队所发现的：语言上的极简主义难以直接应用到团队层面。

像 Ruby on Rails 或 Django 这样的框架存在是有原因的：它们遵循最佳实践，减少冗余代码（样板代码），并通过为你做出成千上万的决定来帮助团队更高效地工作——关于命名、文件结构、路由、测试等方面的决策，以及如何整合一切。

他们提供的正是 Go 有意避开的东西：意见。

当你使用Rails或Django时，你会发现它们自带结构、默认配置和集成工具链。当你使用Go时，你会得到一个空白的起点。

而且那张白纸可能是让人感到自由的——也可能是让人感到无力的。

决策瘫痪症：，来源：cartoonresource / Adobe Stock

对于个人开发者或小型项目而言，Go 缺乏结构可能并不会显得是个问题，但对于构建重要系统的团队来说，它会在各方面造成摩擦和低效。注：原文中的 "serious systems" 保留未翻译，因它可能是一个特定的技术术语或专有名词。

（注释部分可以保留，但根据建议，翻译可以调整为：对于个人开发者或小型项目而言，Go 缺乏结构可能并不会显得是个问题。但对于构建重要系统的团队来说，它会在各方面造成摩擦和低效。）

根据整体调整，最终翻译如下：
对于个人开发者或小型项目而言，Go 缺乏结构可能并不会显得是个问题。但对于构建重要系统的团队来说，它会在各方面造成摩擦和低效。

下面是一些团队常常碰到的情况：

1. 没有共享的惯例.

在这方面并没有统一的标准：项目布局和文件结构、服务边界，甚至编写 HTTP 处理程序的方法都没有标准。这导致：

• 架构方面的内部辩论
• 雪花型服务具有自定义布局
• 因此需要更高的入职成本，每个服务独有的布局导致了这一点

2. 太多，决定，指导太少

在 Go 语言中，许多常见的任务，如后台任务、数据库迁移操作和路由配置，通常是通过第三方库而不是内置工具来处理的。虽然生态系统提供了高质量的选择，但没有一个“官方推荐”的路径或框架，因此团队常常需要花费时间来研究库、将它们连接起来，并保持服务间的一致性。

3. 基础设施自己动手做

因为 Go 文化的特点是反对使用框架，大多数团队最终不得不自己构建所有东西。这通常意味着他们会花费宝贵的开发时间在那些不增加任何独特产品价值的任务上。

• 编写样板代码来连接服务并处理诸如跟踪和授权等横切关注点
• 在每个环境中分别管理密钥和配置
• 使用如 Terraform、Docker 和 CI/CD 脚本等工具手动组装基础设施

4. 团队渐行渐远各自行走

没有强制性的结构，代码库就会变得多样化。不同团队各自形成自己的惯例。就像一位工程师说的那样，"每个 Go 服务都像是一个独立的小宇宙。"

Encore.go 是一个旨在帮助团队更顺利地过渡到 Go 的框架之一。Encore 提供了约定、内置工具和云原生默认配置，以减少冗余代码并减少 DevOps 开销，从而让开发者可以专注于构建产品而不只是基础设施。Encore 帮助团队减少底层架构的复杂性，使开发人员能够更加专注于构建产品，而非底层架构。

“没有Encore，我们团队不可能在那个时间内完成电子书产品的构建。它为我们提供了所需的所有工具和稳定性，使我们的工作更加清晰。”
— Mason Stewart, Bookshop.org 的 CTO

Encore 包含：

• 内置功能: 身份验证、路由功能、数据库迁移功能、服务间连接处理功能等。
• 约定驱动开发: 定义 API、服务、测试和集成基础设施等方面的约定。
• 无需配置: 一条命令启动本地环境，包括所有基础设施在内。
• 可观测性: 默认包含追踪、指标和结构化日志功能，并且可以在 Encore 的开发仪表板中使用。
• 云原生的设计: 支持 Docker 或通过 Encore Cloud 自动部署到 AWS 或 GCP。

与其从零开始使用原始Go，有些团队使用Encore来逐步引入Go——而不放弃他们熟悉的结构。

这在实际操作中可能看起来像这样。

代码片段

定义服务

encore 会将一个 Go 包识别为一项服务。无论是运行应用还是部署，它都会自动配置所需的基础设施并生成连接配置代码。

    /my-app
    ├── encore.app          // ... 以及其他顶层项目文件
    │
    ├── hello               // hello 服务（一个 Go 包）
    │   ├── hello.go        // hello 服务代码
    │   └── hello_test.go   // hello 服务的测试代码
    │
    └── world               // world 服务（一个 Go 包）
        └── world.go        // world 服务的代码

点击全屏按钮以进入或退出全屏模式

请参见应用结构的相关文档，更多详情请参见。

定义API接口

通过使用 //encore:api 注解标记，你可以在纯 Go 代码中定义一个 API 端点：

    package hello // 服务名

    //encore:api public
    func Ping(ctx context.Context, params *PingParams) (*PingResponse, error) {
        msg := fmt.Sprintf("嗨，%s！", params.Name)
        return &PingResponse{Message: msg}, nil
    }

全屏模式: 点击全屏 退出全屏模式: 点击退出全屏

Encore 会自动生成所需的代码和文档。

更多详情，请参阅[定义API]部分，在文档中。

本地运行 (运行本地)

直接运行：

    再跑一次

全屏模式 退出全屏

Encore 将自动搭建本地基础设施以及一个 本地开发仪表板，包含 API 文档、架构图、追踪和日志。

云部署

使用 Encore 开源工具构建 Docker 图像，或者可以使用 Encore Cloud 实现自动化基础架构配置和部署到 AWS 或 GCP 云。

Bookshop.org

Bookshop.org 开始从 Rails 转换到 Go 以提高扩展性。但团队很快意识到 Go 的极简风格也意味着一些代价。

“我们没有使用习惯的约定，这导致了一致性问题。虽然Go语言生成的是单一的二进制文件，但我们仍然需要做大量的Terraform和定制部署工作。”
— Bookshop.org的首席技术官Mason Stewart

采用 Encore 让他们重新获得了 Rails 时期的结构和生产力——并且 Encore Cloud 自动化的 Go 和 Google Cloud Run 的效率，在过程中大大节省了成本。

“每年可以节省超过60,000美元，相比我们原来的Rails应用程序。”
— Mason Stewart，Bookshop.org的CTO

Quiqup（一个快递服务公司）

这有个Quiqup的图片，挺有意思的。

Quiqup 在使用 Rails 时遇到了性能瓶颈，希望迁移到 Go，但又不想承担微服务的开销。Encore 的模块化单体模型非常合适。

"我非常喜欢Encore的模块化单体概念。没有大型团队，微服务很难管理，单体架构同样存在一些问题。Encore在这两者之间达到了完美的平衡。"
— Danny Hawkins，Quiqup的CTO

今天，Quiqup 运行超过 30 项服务及 200 多个 API 端点——没有专门的 DevOps 工程师——这要归功于 Encore Cloud 的自动基础设施和可观测性。

“如果没有Encore，我们上手Go语言的效率会降低2到3倍，需要2到3倍的时间。”
— Quiqup的CTO，Danny Hawkins

Go的极简风格确实强大——但当它拖慢团队时就不是了。

Encore.go 提供了 Go 没有的结构、默认设置和工具，帮助团队更快地完成交付，减少 DevOps 的麻烦和重复工作。

这并不是要替代Go的优势，而是不要强迫每个团队每次都要从头开始构建相同的基础。
(MCP): 模型上下文协议
(LLM): 大型语言模型
(RAG): 检索增强生成
(SSE): 服务器发送事件