Question

我不熟悉模块，正在将它们带到一个新项目中，我正在尝试按照here描述的结构进行建模

这是我的目录结构的示例：

.
├── cmd
│   └── app_name
│       └── main.go
├── go.mod
├── go.sum
├── internal
│   └── bot
│       └── bot.go
└── pkg
    ├── website_name
    │   ├── client.go
    │   ├── client.options.go
    │   ├── server.go
    │   └── server.options.go
    └── lib
        └── lib.go

这在习惯上是正确的吗？我知道目前还没有很多共识，但是我想遵循最佳做法。
当我运行go build时，我得到了“意外的模块路径“ github.com/ragurney/app_name/cmd/app_name””，但是当我运行go build ./...时，它可以工作。为什么？

当我将main.go移到顶层时，一切都会按预期进行。我是否应该不对模块使用/cmd模式？

Answer 1

要回答您的第一个问题，它要有充分的判断力，并且您最喜欢的任何其他人也应该很容易理解的东西（我认为很好）。

要回答第二个问题，原因是go build ./...相对于根目录中的go build起作用是因为./...从当前目录（根）开始并搜索所有程序条目点并建立它们。当您将main.go移到根目录下时，有了这些新信息，go build的工作就变得有意义了，因为它只在当前目录中查找。

您可以明确地说出go build ./cmd/app_name。

您的应用程序结构与模块完美配合，因为我使用与之非常相似的东西（https://www.ardanlabs.com/blog/2017/02/package-oriented-design.html），而模块对我来说则很好。

Answer 2

据我所知，您的项目结构没有错。对我有用的是从项目根目录

运行go build / run命令。

例如 go run github.com/username/project/cmd/somecommand

go build -o somebinary github.com/username/project/cmd/somecommand

使用/ cmd结构构建Go模块时出错

2 个答案: