标题： [求推荐] 寻找开箱即用的 Go Web 模板（需 GORM + DI + 垂直切片架构），顺便探讨一下 Go 社区对 DI 的态度
yikyo · 14 小时 59 分钟前 · 982 次点击大家好，
最近在做 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 语言没有任务基础，也是最近刚尝试使用。上面的讨论如有不当之处，请多多包涵。
 |
1
NoobPhper 14 小时 52 分钟前
把一件复杂的事情做简单是件很难得事情， 不要平白无故的增加 系统熵
|
 |
2
viking602 14 小时 48 分钟前
社区里用 ent 的居多 我们自己也是用的 ent gorm 的话我建议是自己搓一个脚手架 自己搓的才是最符合自己需求的
|
 |
3
Ayanokouji 14 小时 44 分钟前
推荐这个项目，进行定制自己的 template 。https://github.com/samber/do-template-api
|
 |
4
Gilfoyle26 14 小时 43 分钟前
go 的 Web 还有可选的嘛，除了 gin 还能选择什么？
不过我是直接手搓 web 框架，极致的手工业。 |
 |
5
yikyo OP |
|
6
yikyo OP @Gilfoyle26 年后才开始接触 go ，扡 gin fiber echo iris 都看了一下。
|
 |
11
Dorathea 14 小时 29 分钟前
GIN 应该可以满足你的大部分需求, ORM 有对应的库(GORM)
至于 DI 的问题, 可以了解下 golang 的 interface |
 |
12
Immortal 14 小时 25 分钟前
不明白为什么上面说 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 一类更方便,所以推荐. |
 |
13
OrangeAdd 14 小时 17 分钟前
个人实际工作下来，大部分项目其实都是一个路由框架（ Gin ）、ORM 框架（ GORM ）就够用了，需要啥基本都是 new 一个就可以了。
|
 |
15
gitrebase 14 小时 4 分钟前
Go 里的 DI 没有一个像 Java 里的 DI 那么好用，真不如在 main.go 里手搓几行 new(XxxService)
|
 |
16
bingo084 14 小时 4 分钟前
垂直切片架构这个，我之前也很想用，但是发现按这样分包之后，很容易出现循环依赖，然而 go 里又不允许包循环依赖。。不知道怎么搞，最后还是横向分层了。
|
 |
17
BeautifulSoap 13 小时 48 分钟前  2
很多 Go 程序员嘴巴上说 Go 不需要框架，不需要 DI ，不需要分层。面对这些东西的讨论的时候就仿佛触发了什么底层的哈气代码一样有一种天生的仇恨。
但矛盾的是，实际上真工作中遇到项目对应复杂度的时候，排除掉堆屎山的，大部分人都自己手搓出了对应的简陋的 DI 、DDD 分层框架。只不过大部分人要不根本没意识到自己已经这么干了（取的名字千奇百怪，结构千奇百怪），要不就根本不想承认自己已经这么干了。 话题偏了，回到 lz 问的问题，我的 Go 项目一般都是在 Gin 上自己分层，DI 虽然有 wire 这东西但真的非常难用，一般我喜欢用 dig 做 DI 。为了避免动态 di 在运行时出问题的坑，我所有依赖都尽量通过工厂函数在服务器启动时完成注入，从不在运行时动态获取依赖。这样一旦依赖出问题就能在启动服务的那一瞬间报错崩溃注意到 ORM 以前喜欢用 GORM 但是后来发现 GORM 这玩意实在没有多好用，现在喜欢直接 sqlx 。而且我最近的项目很多都涉及到 serverless+Dynamodb ，所以通过分层框架实现多数据库兼容已经是现在项目的基本前提了，一旦系统设计不局限于 sql 要考虑兼容性，就能立刻扩展系统设计水平和意识到分层的重要性 |
 |
18
heartleo 13 小时 38 分钟前
|
|
19
yikyo OP 以上回复我都会认真参考，我作为新手闯进 go 语言的世界，有点颠覆我的想象，所以发个帖讨论一下。
感谢楼上各位的回复。 |
 |
20
ColinLi 13 小时 25 分钟前
使用 wire
|
 |
21
wangtufly 13 小时 22 分钟前
kratos,你就用吧
|
 |
22
Hstar 13 小时 10 分钟前
你这个喜好，用 Go 是给自己找事。
就说你喜欢的‘按“业务模块”来组织代码’，天才，如果多个“业务模块”之间有循环引用怎么办，比如新增了一个 account 模块，想调用 user 的 service ，然后发现 user 的 service 也想调用 account 的 service 。只能使用 DI ，把所有对象在 root 上初始化好，按需调用对吧？你发现了吗，你凭空增加了复杂度，而且几乎没有带来任何正向收益，可能就满足了你的喜好。 |
 |
23
explore365 13 小时 5 分钟前
https://github.com/goravel/goravel Go 版的 Laravel
|
 |
24
kfpenn 12 小时 26 分钟前
去年有一个项目尝鲜的用了 DI ，反正用下来没感觉有什么便捷的，以后应该不会特地去用了
|
 |
25
treblex 12 小时 22 分钟前
https://github.com/maximhq/bifrost 这个是个 ai 转发，我觉得做的很漂亮，动态插件模式，学到很多
web 框架最终还是做了个工具包，然后项目模版直接使用 gin ，https://github.com/lazyfury/bowlutils 目录结构是这样，不过框架无关的，不是强制的  |
 |
26
NaVient 10 小时 55 分钟前
在不同的厂写过几个复杂业务有的用 DI ，有的不用。个人用下来感觉 DI 在 Go 里是完全多余的
|
 |
27
redbule 10 小时 9 分钟前 2
go 羸弱的元编程能力决定了它的 DI 不会好用，老老实实大道至简就行了
|
 |
28
wogogoing PRO |
 |
29
ljian6530 7 小时 13 分钟前
最近写的项目用 nunu ，大佬可以看看是否满足需求 https://github.com/go-nunu/nunu
|
 |
30
70k 6 小时 43 分钟前
Claude 3.5 的时候他给我用了 go-chi 然后去看了一眼感觉比 gin 简洁明了 以后就准备用这个了
现在用 ai 写业务逻辑 自己不准备维护的话直接 Sqlx 就行了 自己想维护就让 ai 分一个数据库操作的层 |
 |
31
liuliuliuliu PRO 我不是很理解，做 web 为啥用 go?
|
 |
32
xpzouying 6 小时 12 分钟前
之前研究过整洁架构的时候，设计了一套架构，可以看看：
https://github.com/xpzouying/go-clean-arch 用的是 wire 进行依赖注入。 --- 不过个人觉得非必要不要搞这么复杂，特别是团队协同中，是双刃剑。（真实的生产经验。。。） 一方面：如果没有很好的规范，确实团队协同中，很快代码就会乱掉，代码只要能放到一个地方编译通过就直接放到了，后面也不会轻易移动它。（谁能扛住生产的线上问题呢？。。。） 另外一方面：如果要引入规范，特别是 DDD / 整洁架构这套的话，那么就需要让全部团队的同学熟悉对应的规范，然而团队中每个同学对于 **规范** 以及 **业务** （非常重要）的理解是不一样的，所以一定要做好 code review ，否则也会是屎山。 --- 可以先看看我整理的这套整洁架构的思想规范和代码模板，至少在原来公司的生产环境用过。 |
Select Language