(与
go1.23.3
,如果重要的话)
嵌套目录:
./
├── a/
│ ├── a1/
│ │ ├── a1.go
│ │ ├── a2/
│ │ │ ├── a2.go
│ │ │ ├── a2_test.go
│ │ │ └── go.mod
│ │ ├── go.mod
│ │ └── go.work
│ ├── a.go
│ ├── go.mod
│ └── go.work
├── b/
│ ├── b.go
│ └── go.mod
├── c/
│ ├── c.go
│ └── go.mod
└── go.mod
go.mod:
a
、a1
、a2
是嵌套的 go 模块。a
、b
、c
是同一级别的 go 模块。去工作:
a/go.work
:使用 b
和 a2
a/a1/go.work
:使用 c
和 a2
在我的测试中,它显示:
a2
可以使用b
,但不能使用c
,也就是说a/go.work
生效,是外层go.work
。a/go.work
,那么a2
现在可以使用c
,这意味着a/a1/go.work
生效了。问题:
go.work
中,go 模块将搜索最外层的 go.work
并使用它?a/go.work
和a/a1/go.work
同时生效吗?
go.work
,如果没有找到,则搜索内部级别,甚至以相反的顺序。Java
的 classloader 的工作方式一样。)。背景(如评论中所述):
go.work
。go.work
的行为,以便我可以更好地决定如何使用go.work
,因此出现了问题。(我发现了更多与问题中提到的规则不同的规则。)
规则(我现在找到了):
go.work
那个use
模块。示例:
在问题的目录树中:
a/go.work
生效时间为 a/a1/a2/go.mod
。go.work
使用了a2
。a2
的 a/go.work
语句中删除 use
,则 a/a1/go.work
对 a/a1/a2/go.mod
生效。a/a1/go.work
成为使用go.work
的最外层a2
。规则清晰了,现在我可以更好地整理
go.work
文件了。