做个调查：你们的 Go 项目中会用到依赖注入吗？比如用到如 wire、dig 之类的库？

之前用的 wire ，新项目试了下 fx ，感觉要流畅一些。至于使用 DI 框架的好处，那就是定义好初始化函数，剩下的交给框架就行了。个人还是蛮喜欢的。

我们项目里没做

用到了，使用 google 的 wire: https://github.com/go-eagle/eagle-layout

依赖注入啥时候和 java 绑定并成了一种邪恶的东西呢。。。他明明是一种思想

目前 uber/fx

这之前已经有讨论过了 我倾向不用
package 下直接初始化 struct 就可以了
一楼讲的其实就是把 struct 当命名空间用 很 js 的方式
go 已经有命名空间了 所以不用这种方式实现一样结果更单纯
spring 下的与一楼讲的相似 只不过是换成阵列 徒增性能损耗
这种方式因语言本身 import 功能就已经解决依赖问题
只要没 import 循环问题即可 其它语言的都可能会有依赖循环问题 这是种对语言特性深度了解并使用本身具备的功能减少过多嵌套的方式个人认为最佳

至于测试... 可以用 go test
本身就已经有的功能

虽然我本身不怎么想写测试

还有一点 直接用 import 在编译或开发时就会检查依赖了 错了代表设计不合理

学习了本贴和一些链接的内容，然后决定继续手搓

就算用 di 也不该用 dig ，应该用 fx （

看到这标题我真是一口可乐喷出来了.
go 的出现本来就是为了规避这些复杂的要死的设计模式.
大道至简.
结果你把依赖注入都搬出来了.
那你为什么不直接用 ASP.NET Core 算了.

wire 、dig 之流太恶心，不如直接用 init 来依赖注入，当然要注意 init 顺序

@totoro52 #44 因为某些人给自己打上了思想钢印

哈哈哈，月经贴鉴定完毕，总结一下 :-)
- 个人的、不写单测的项目不需要用依赖注入，代码抽象的复杂度会上升
- 多人参与的、迭代频繁的项目，用依赖注入会让大家都舒服，用类似的模式写代码和测试

刚好回头刷了下我早前开源的 Go 依赖注入框架，发现多了几个 star……

https://github.com/go-kod

fx 挺好用的

以前用过 wire ，现在用 fx 比较多；不用依赖注入的话，业务的单元测试会很难写

@matrix1010 1.设计的时候解耦一下、测试专门搞个 mock 实现； 2. go 有几个 monkey 库可以用

说 fx 好用的我都点了赞

把一件复杂的事情做简单 是件很难得事情看来

以前试过依赖注入框架，后来看 flutter 的时候发现了 riverpod 用的 provider 方式，自己写的小项目也改成类似的方式感觉比较顺手，还可以借助一点 go 本身的循环依赖检查
https://gist.github.com/yeziyezi/97d4e75dc59e5d9d40f3d88889552cb5