Go 语言依赖约定俗成的文件结构而非语法强制：module 根目录须有与导入路径一致的 go.mod；main 函数在 package main 中，推荐置于 cmd/ 下；internal/ 控制包可见性，pkg/ 表示公共 API；测试文件须同目录且以 _test.go 结尾。
Go 语言没有强制的文件结构，但 go 工具链和标准实践依赖一套约定俗成的布局——它不是语法要求，而是构建、测试、导入和发布能正常工作的前提。
module 根目录必须有 go.mod
从 Go 1.11 起，模块（module）是依赖管理和版本控制的基础。没有 go.mod，go build、go test 等命令会退回到 GOPATH 模式（已弃用），且无法正确解析本地或远程 import 路径。
-
go mod init example.com/myapp是创建它的唯一可靠方式，不要手动新建空文件 -
go.mod中的 module 路径必须与你期望被他人import的路径一致（例如import "example.com/myapp/pkg/util"暗示 module 名为example.com/myapp） - 子目录里不能再放
go.mod，除非你明确要切分独立模块（多模块仓库需谨慎）
main 函数必须在 package main 且文件名无硬性限制
可执行程序的入口由 package main + func main() 共同标识，不依赖文件名。但实际组织中，常见做法是：
- 命令行工具放在
cmd/xxx/main.go（如cmd/myserver/main.go），便于一个仓库管理多个二进制 - 避免把
main.go和业务逻辑混在同一目录，否则go test ./...会尝试编译所有.go文件，可能因缺失 flag 或配置 panic -
main()应极简：只做参数解析、日志初始化、依赖注入和启动，其余逻辑抽到internal/或pkg/
internal/ 和 pkg/ 的权限边界很关键
Go 通过目录名隐式控制包可见性：internal/ 下的包只能被其父目录或祖先目录的代码 import；pkg/（非关键字，但社区惯例）通常表示可对外暴露的公共 API。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 误把本该放
internal/的实现细节放到pkg/，会导致外部用户意外依赖不稳定接口 - 把
internal/xxx放得太深（如internal/a/b/c），会让同模块内其他包难以复用，也增加重构成本 -
internal/不提供编译保护——如果外部模块路径恰好能绕过检查（比如 symlink 或 GOPATH 模式），仍可能 import 成功，别当安全边界用
测试文件必须和被测代码同目录，且命名以 _test.go 结尾
Go 的 go test 默认只运行与当前包同目录、后缀为 _test.go 的文件，并自动区分单元测试（TestXxx）和示例测试（ExampleXxx）。
- 不要建单独的
tests/目录——那样会变成另一个包，无法访问原包的未导出标识符（unexported fields/functions） - 集成测试或端到端测试可放在
integration/或e2e/，但需用//go:build integration+go test -tags=integration显式启用，避免污染常规测试流程 - 基准测试（
BenchmarkXxx）同样必须同目录，且仅在go test -bench=.时执行
真正容易出问题的，往往不是“该放哪”，而是“为什么这个包突然 import 不到了”或者“为什么 go test 没跑我的测试文件”——归根结底，是忽略了 go.mod 路径、目录名隐含的可见性规则、以及测试文件命名这三个刚性约束。
