我使用 fx 大概两年左右，下面就针对楼主各点给出我的看法。。

PS1. 新出的 fx.Module 还没想到用得到地方，可能我项目不够大吧。

# 手动维护依赖属性
使用 fx.In 参数对象解决依赖问题，我一般一个依赖一个包，所以都是这样写的 New 护士

```
// dep 专门用来给 fx 注入参数
type dep struct {
fx.in

dao dao.M // 为了单测方便，数据层的一般都提供 interface
busi busi.M
}

// 这里看这个模块的情况，想被 mock 就写
// type M interface {
// bala()
// }
type M = *module

type module struct {
*dep // 内嵌指针就好了

some int // 内部变量
}

// 私有参数，让其无法手动调用，只用来 fx
func New(d dep) M {
return &module(dep: &dep)
}

```

server->service->db Provide 定义问题，因为我每个 Provide 都分包的，
所以要增加一个 fx.Invoke 去注册 service 到 server

所以，Server 是单独 New 出 Provide 的，无依赖(他被人依赖)
所以就有三个 fx.Provide
1. dao.New 无依赖
2. service.New 依赖 dao
3. server.New 无依赖
两个 fx.Invoke
4. service.Reg 依赖 server, service ，实现 server.Reg(service)
2. server.Life 注册 server 启停，注意最好用 fx.Lifecycle 注册，不要直接调用

如果嫌弃一个 service 定义两个 Option 很麻烦的话，
实际上，service.M 基本不会被其他 Provide 使用，所以也可以省略 service.New ，
直接在 service.Reg 中完成，New 和 绑定操作

可以看出。实际上加属性，也只需要修改一个地方，即 dep 成员，整个也很简单

# 写单元测试有点麻烦
与楼主相反，我觉得倒是写 UT 非常简单。。

由于我按每个 Provide 分包，所以 UT 分为 Provide 内 UT ，Provide 间 UT

Provide 内 UT ，直接 new 对象，按需初始化成员就好了，不要走 New 函数创建对象，
因为 和其他的 Provide 内 无关，所以 UT 根本不需要 fx 介入，比如我上面依赖 dao.M 的例子
可以直接创建该成员 mock 对象

Provide 间 UT ，由于 fx 的特殊原因，以及 go 的循环引用问题，所以 Provide 间 UT 只能用在
黑盒测试，我是这么处理的

有一个 app 模块 管理所有 Provide/Invoke ，main 直接调用 app.App().Start() 启动程序

```
func TestXXX(t *testing.T) {
var m some.M
defer fxtest.New(t, app.Provides(), fx.Populate(&m)).RequireStart().RequireStop()
}
```

你还可以用新出的 fx.Replace 替换链上的依赖为 mock

# 其他点
5. 性能损失：fx 只作用于你程序的初始化阶段。。。这个阶段谈性能损失？
6. 调试、维护略复杂，你可能是没用 fx.Logger ，我用了 2 年都没有调试过 fx