标题： [求推荐] 寻找开箱即用的 Go Web 模板（需 GORM + DI + 垂直切片架构），顺便探讨一下 Go 社区对 DI 的态度

[yikyo]

大家好，

最近在做 Go 的 Web 项目选型，看了一圈生态里的框架，希望能找到一款偏向开箱即用的模板。想请大家推荐一下：

我理想中的框架特性：

• 开箱即用：不想从零开始拼凑路由、日志、配置和 ORM 等基础组件，希望能有一套成熟的默认约定。

• 深度集成依赖注入（ DI ）：希望框架能很好地管理对象的生命周期和依赖关系。

• 集成 GORM：因为业务原因，需要 GORM 作为核心的数据库 ORM 工具。

• 支持垂直切片架构（ Vertical Slice Architecture ）：这点极其重要！我不希望代码是按“技术职责”横向分层的（比如所有 controller 在一个包，所有 model 在一个包）。我希望框架的推荐实践是按“业务模块”来组织代码的。例如一个用户的业务，其结构应类似于：

/user
  ├── user.model.go
  ├── user.repository.go
  ├── user.service.go
  └── user.controller.go

不知道大家有没有符合上述要求的脚手架或框架推荐？

另外，还有一个疑惑想和大家交流讨论：

在研究 Go Web 框架和各种开源模板的过程中，我发现一个现象：在 Go 语言生态中，大家似乎对“依赖注入（ DI ）”并不是特别热衷？

在 Java (Spring) 或 C# (.NET) 里，DI 几乎是刻在骨子里的标配，不使用 IoC 容器简直没法写代码。

想听听老哥们的看法，为什么 Go 的社区风气对 DI 容器显得比较克制？

是因为 Go 强调的“大道至简（ Keep it simple ）”和显式编程哲学？

是手动传递依赖在 Go 里写起来并没有那么繁琐？

还是说使用反射（ Reflection ）做运行期 DI 在 Go 中有什么性能隐患或难以调试的坑？

期待大家的框架推荐以及对 DI 问题的看法，提前感谢！

前提，本人对 go 语言没有任务基础，也是最近刚尝试使用。上面的讨论如有不当之处，请多多包涵。

[NoobPhper]

把一件复杂的事情做简单是件很难得事情， 不要平白无故的增加 系统熵

[viking602]

社区里用 ent 的居多 我们自己也是用的 ent gorm 的话我建议是自己搓一个脚手架 自己搓的才是最符合自己需求的

[Ayanokouji]

推荐这个项目，进行定制自己的 template 。https://github.com/samber/do-template-api

[Gilfoyle26]

go 的 Web 还有可选的嘛，除了 gin 还能选择什么？

不过我是直接手搓 web 框架，极致的手工业。

[yikyo]

@Ayanokouji
@viking602

感谢，我晚点去看一下

[yikyo]

@Gilfoyle26 年后才开始接触 go ，扡 gin fiber echo iris 都看了一下。

[aapeli]

@yikyo #6 我的意见是能不用 DI 就不用 DI ，用 AI 做 Code 生成，没必要再增加一步 DI 过程。

[lifei6671]

@yikyo #6 推荐一个邪修 go web 框架：goframe ，这个框架有点反人类。

[yikyo]

@NoobPhper 刚接触 go 有点不适应。跟我的想象中的不一样。

[yikyo]

@lifei6671 不搞。。。怕搞坏了。。。

[Dorathea]

GIN 应该可以满足你的大部分需求, ORM 有对应的库(GORM)

至于 DI 的问题, 可以了解下 golang 的 interface

[Immortal]

不明白为什么上面说 GoFrame 是邪修.
写 Go 快 10 年了,从一开始的 Martini/Beego 时代,到后面折腾 gin/echo 一类"路由框架",也用过 go-zero 和 GoFrame.
现在 web 项目如果没有特殊要求我就默认用 GoFrame 了.

Gin/Echo/Chi 一类就像我上面说的更像"路由框架".作为轻量级的 Web 框架有利就有弊
如果项目不是按传统的 MVC 这类架构来展开,需要使用 DDD 这样的,那么基本只能选这类框架自己搭建脚手架.
容易上手写写小项目,但是做中大型项目需要一些底子来组织文件/项目的结构,不然越写越乱.
还有 Model 层需要自己去找合适的.Gorm/Ent/Sqlc 这类,个人推荐 Echo+Sqlc

写到后期其实 Web 基本就那么一回事.Router->Logic(Controller)->Service(公用逻辑封装)->Model.
Go-Zero/GoFrame 基本都做到了这些,GoFrame 的 Model 感觉比 Gorm 一类更方便,所以推荐.

[OrangeAdd]

个人实际工作下来，大部分项目其实都是一个路由框架（ Gin ）、ORM 框架（ GORM ）就够用了，需要啥基本都是 new 一个就可以了。

[Immortal]

@Immortal #12
是我审题不清了.
OP 情况那就 Echo+Gorm 吧

[gitrebase]

Go 里的 DI 没有一个像 Java 里的 DI 那么好用，真不如在 main.go 里手搓几行 new(XxxService)

[bingo084]

垂直切片架构这个，我之前也很想用，但是发现按这样分包之后，很容易出现循环依赖，然而 go 里又不允许包循环依赖。。不知道怎么搞，最后还是横向分层了。

[BeautifulSoap]

很多 Go 程序员嘴巴上说 Go 不需要框架，不需要 DI ，不需要分层。面对这些东西的讨论的时候就仿佛触发了什么底层的哈气代码一样有一种天生的仇恨。
但矛盾的是，实际上真工作中遇到项目对应复杂度的时候，排除掉堆屎山的，大部分人都自己手搓出了对应的简陋的 DI 、DDD 分层框架。只不过大部分人要不根本没意识到自己已经这么干了（取的名字千奇百怪，结构千奇百怪），要不就根本不想承认自己已经这么干了。

话题偏了，回到 lz 问的问题，我的 Go 项目一般都是在 Gin 上自己分层，DI 虽然有 wire 这东西但真的非常难用，一般我喜欢用 dig 做 DI 。为了避免动态 di 在运行时出问题的坑，我所有依赖都尽量通过工厂函数在服务器启动时完成注入，从不在运行时动态获取依赖。这样一旦依赖出问题就能在启动服务的那一瞬间报错崩溃注意到

ORM 以前喜欢用 GORM 但是后来发现 GORM 这玩意实在没有多好用，现在喜欢直接 sqlx 。而且我最近的项目很多都涉及到 serverless+Dynamodb ，所以通过分层框架实现多数据库兼容已经是现在项目的基本前提了，一旦系统设计不局限于 sql 要考虑兼容性，就能立刻扩展系统设计水平和意识到分层的重要性

[heartleo]

DI 可以使用 https://github.com/google/wire 或 https://github.com/uber-go/fx

[yikyo]

以上回复我都会认真参考，我作为新手闯进 go 语言的世界，有点颠覆我的想象，所以发个帖讨论一下。

感谢楼上各位的回复。

[ColinLi]

使用 wire