@blless 不是很同意。

如果没有做好代码分层，无论是 fx ，还是 getInstance ，都无法避免循环依赖。

可能和你想的 getInstance 不一样，我说是构造工厂

1. 我所需要的对象都来自于工厂，调用者不必关心工厂怎么初始化的，也不关心工厂如何实现的、更不关心工厂依赖什么
2. 调用者**只关心工作的输入输出**符合接口规范。这跟 fx 是一致的。
3. 如果工厂如果出错了，应该保证返回 err 或者像 fx 那样返回”failed to build xxx“的 panic
4. 不必要的依赖跟 mock 是两个层面的事情吧。如果是不必要的依赖，最好直接不初始化才对

不太理解你说的`getInstance 再 getInstance 循环`是什么情况，循环依赖在编译前就会报错不是吗？

说太多不如上一段实际的代码，拿我们的之前一个项目来说，简化结构如下：

```
app/
settings/
fx.go
config.go
store/
fx.go
cache/
fx.go
redlock/
fx.go
redlock.go
redlock_test.go
pg/
es/
kafka/
....
service/
service1/
service2/
....
main.go
```

虽然引入了 fx, 但是加功能测试`redlock_test`时就发现有循环依赖:
```
$ cat ./store/cache/redlock/redlock_test.go
func TestRedlock(t *testing.T) {
fx.New(
settings.Module,
fx.Provide(xxx),
....
}
$ go test -v ./store/cache/redlock/
package app/store/cached/redlock
imports app/store
imports app/service
imports app/settings: import cycle not allowed in test
FAIL app/store/cache/redlock [setup failed]
```

原因是, 因为 app/settings/fx.go 包含了依赖了各种配置的构造器

```
import (
"app/service"
"app/store/pg"
"app/store/es"
"app/service/..."
...
)


// yaml 文件配置解析
func GetConfig() (config *Config) {
...
}

// 各种配置的构造器
func NewRedisUniversalOptions(config *Config) *redis.UniversalOptions {... }
func NewPostgresOptions(config *Config) *pg.Options {...}
func NewEsOptions(config *Config) *es.Options {...}
func NewService1Options(config *Config) *srv1.Options {...}
....

var Module = fx.Module("settings",
fx.Provide(
GetConfig,
NewRedisUniversalOptions,
NewPgOptions,
NewEsOptions,
NewService1Config,
....
),
)
```

可以看到
1. setting 基础配置，依赖其它种 store(rddis/es/pg/kafka...)，甚至 service 的 Options 类
2. setting 是其它库的上层，而不是底层。只有顶层的 main.go 可调用 setting ，其它不行
3. 我们就不能在其它包内引用这个 setting, 想引用的话就需要重新对配置解耦合。

还是那句话，无论是工厂还是 fx ，代码如果没有做好良好的解耦分层，项目都不会那么好维护。

@MengiNo 用-v 映射，就无法自动补全了。除非`-v /data/demo:/data/demo` 保持一致

vlang 还是在认真做事的。而木兰的作者已经为虚假宣传道歉了，跟透明计算，还有红芯浏览器没有什么区别

稚晖君很强大，不过这款键盘还没有多少让我更换键盘 atom84 的冲动，除了那个空格键的滑动不错。
谁能设计一款让我丢弃 macbook touchpad 的键盘，我保证冲动。（ tinkpad 的小红点可不好用）

@a132811 说“唯一的区别”肯定不对。我使用感受是：
1. fx 提供了生命周期的管理，保证模块加载、退出的有序性。则单纯靠单例工厂，就不容易做。
2. fx 查看整个项目的执行的依赖比较直观。

其它区别（优点），我想不到什么了

@mcfog 是否可展开解释一下？

1. 我例子中的测试代码 TestWorkflow 不用 fx 有更好的方式吗？这个情况我倒是很常用
2. 用单例工厂 不等于 堆代码堆逻辑 吧？单例工厂把每个实例缓存放在私有变量。即然使用到 fx 管理代码，本身就使用了单例模式（每个依赖就是一个单例）。如果是单例变变例，也是一样的管理。唯一的区别是——单例的缓存实例是放在 package 作用域，fx 是把缓存实例放在 app 内
3. IDE 只能自动处理一小部分 snippet ，就是我上面说的样板代码（单测 1 ），我写测试时还是要手动维护额外的依赖管理（单测 2 ）

@janxin
有 mock, 但不全 mock ，不追求所有的东西都 mock ，算是介于单测和功能测试之间吧。

另外，性能损失以及调试问题不大，所以我把这两个痛点放在了最后。


@pmx1990 我的使用感受跟你不太一样，我是觉得大项目使用 getInstance 工厂来组织代码会比 Fx 好用。
不知道
为了避免 getInstance 混乱，需要坚持一些原则：存放实例缓存的命名统一前缀如`_inner_`、缓存变量小写私有、
工厂名要有统一前缀、实例工厂放在统一固定文件名、严格遵守 package 的上下分层。也能做到 fx.Module 那样清晰组织代码的

感觉这东西完全可以做成 PWA 应用

我在想，站长是不是最近买了房，要还房贷啊？

我支持收费，据说是 MIT 协议的，好像也说得过去——就是不知道有没有问其它 PR 贡献者意见

无论翻译的好还是差，贵还是便宜，明码标价，合情合理——虽然有违传播知识的初忠

不过我感觉，从程序员身上挣这个钱，有点难——虽然中文用户的基数大

直白一点，护肤记 /护肤瓶

@iLionel vim 按 esc 会进入命令模式，此时如果是中文输入法必须要手动切换成英文
--------
我发现 neovim v0.7.2 居然可以自动切换中英文

我用的清歌五笔，倒是内置了 Switch keyboards based on apps

但是不能实现 vim 按 esc 自动切英文，你这个能支持吗？

@acapla 什么公司这么良心？

@Alliot 开不开 mouse 都不行的。
应该是 terminal 本身拦截了 command

@a132811 打错了，是 niz atom84(居然打成 87 了)

以前用的机械，声音太大，后来送人了

后来用 niz atom68 的电容，35g 压力，但是不习惯 F1-F12 要按双手双键组合键、与 ESC 与～/`键也不能放左上角

目前用的 niz atom87 的电容，带了 F1-F12 ，交换了 cap-lock/ctrl ，其它键映射成 mac 键一样，舒服了