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

研究了这几个库, 对代码的结构组织结构影响还挺大的, 和 java 的 spring 完全不是一个概念
这么说吧, 不如就是一个全局的 Container struct, 里面定义了各种变量, 需要用的地方再引入, 这样对心智负担也较小, 更容易维护

赞同楼上兄弟说的，感觉 Go 根本没必要用这些 DI 库，徒增复杂度

我不会主动使用，但是如果有一个对技术和 golang 半懂不懂的领导一定要求你要使用这个东西——即便他连这个 wire 的基础使用连一知半解都算不上——那我也没有办法。

我不赞同，但是如果你坚持那我就没必要坚持找不快。

建议调查加上: 你们的 Go 项目写单元测试吗？写单元测试却没有使用依赖注入的情况下是如何 mock 各种依赖的

小项目不用，大项目不得不用。

用依赖注入，但不使用框架。
从这个项目学的思路 https://github.com/mikestefanello/pagoda

#4 同意，我自己用依赖注入的时候也发现单元测试没法搞。

框架以前我都推荐 Grafana ，但 Grafana 太复杂了而且有大量历史遗留代码，很多地方风格也不太统一。有兴趣的可以参考一下我最近的这个项目: https://github.com/Yiling-J/tablepilot. 在 Go 的基础上支持 CLI+WebUI+App, 同时写单元测试

对于说 go 用不到 di 的，我很好奇你们平时用的项目都小到各种依赖能手动注入的吗？

对于大点的项目，注入依赖项肯定需要 di 框架。我主要用 dig

@jollywang 全局的 Container struct （说白了就是全局变量存在那的一个 singleton 模式）的话，我就比较好奇，你这存在那的对象是在 init 阶段就 new 好还是等需要的时候再 new （即 lazy init ）？后者的话那就必须要考虑线程安全问题。再一个既然是 singleton 了，如果我想要每次调用都生成一个全新的对象的话，是不是还得实现非 singleton 的功能。
那么这一套实现下来，在我看来不就是实现了半个 di 框架了吗

不用。90% 的项目其实都没必要依赖注入，即使是 java 也一样

同好奇，如果不用依赖注入，你们单侧依赖怎么 mock ?

单元测试和依赖注入没什么关系吧，怎么楼上扯歪了，golang 这么多内置库没用依赖注入也不影响单元测试，一个包内的全局变量，然后包内测试刘 OK 克

@MemoryCorner interface+monkey

我主导的一个大项目用到了自己写的 ioc ，通过依赖注入来适应不同的 tenants 。
单元测试覆盖所有 ioc 托管对象的接口，业务代码写完只需要去测试环境做一下集成测试就行。
虽然复杂度确实提升了，但后期维护+新增租户啥的都很方便，没啥负担

https://yangjunhui.monster/t/1094915 半年经贴，回答者都是些熟面孔，回答也类似。

你都用 Go 了……那你猜 Google 为什么要写 wire ？

https://github.com/zzztttkkk/dic

我自己也弄了一个。

不会，主要是不好用，徒增复杂度。

那你为啥不用 java