不要跨包链接文件，这是不好的做法。首先，代码会重复。另一方面，标识符会重复，这意味着表示相同的实体（例如类型或函数），但它们将是不同的。例如，如果链接和structs.go将包含type Response定义，你会有两个不同的类型server.Response和routines.Response，这只会带来更多的混乱。
一种解决方案是将structs.go放入自己的包中，例如model，所有依赖于它的包都可以导入它（例如main，server和routines）。
在一个理论示例中：如果软件包A导入软件包B，并且两者都需要structs.go，那么它也可以添加到软件包B中。如果存在只需要structs.go的软件包C，那么创建自己的包model会更明智（所以包C不需要导入/知道包B，只需要新的model包）。
另外，如果没有其他人会使用您的包，并且它不是太复杂，那么将其组织成多个包可能不值得麻烦。

可以只在一个包中定义一个类型，并以这种方式在其他包中使用它：

package one
type A struct{ B int }

字符串
变式1：

package two
. import "one"
var name A

型
变式2：

package two
import "one"
type A = one.A
var name A

型
我更喜欢第二种。

从golang 1.18开始，你可以使用go.work文件来创建一个工作区。注意：这不会解决包之间共享结构体的问题，但是你可以在同一个包中的文件之间共享结构体。在下面的例子中，“ONE”类型用于示例化整个XPTO模块。任何这种类型的变量都可以访问所有接收器为 *ONE的方法，无论你在包中的文件是什么。
文件A包xpto类型ONE结构{}
文件B包xpto
File C package xpto
来源：https://go.dev/doc/tutorial/workspaces

一般来说，尽量使结构体接近它们的用例，我们通常使用以下方法（尽管它非常依赖于上下文，所以与其说是一条规则，不如说是一个指南）：

/web/model/...         // API request/response types
/model/...             // DTOs used internally throughout the app
/repo/items/...        // or /repo/entity/... Objects persisted to DB
/service/interfaces.go // to describe the service layer in full, sometimes struct DTOs makes sense there

字符串
我也会避开“structs.go”文件-通常每个文件都有一个结构体更好，因为你可以更清楚地添加编组和其他行为-并命名文件对齐，例如：

/web/model/create_order_request.go
/web/model/create_order_response.go

型