多数项目不该在 cmd/、internal/ 或 pkg/ 子目录执行 go mod init，否则会破坏单模块结构，导致 import 路径解析失败、构建报错；唯一例外是明确要将子目录发布为独立可 go get 的库。
子目录下执行 go mod init 会破坏单模块结构
多数项目不需要、也不该在 cmd/、internal/ 或 pkg/ 子目录里单独运行 go mod init。一旦这么做了，Go 工具链会把该子目录识别为独立模块，导致根目录的 go.mod 失效，import 路径无法解析，甚至 go build ./cmd/app 报错 no required module provides package。
常见诱因包括：IDE 自动初始化、新人误操作、复制粘贴脚本没删掉子目录路径。
- 唯一合理场景是：你明确要将某个子目录（如
pkg/utils）发布为可被外部go get的独立库，且它有自己完整的版本生命周期 - 若只是内部复用，所有代码应归属同一模块——根目录一个
go.mod就够了 - 验证方式：运行
go list -m，输出必须是根模块名（如example.com/myapp），而不是example.com/myapp/cmd/app
import 路径必须匹配根模块名，不能用相对路径
子目录里的文件（比如 cmd/api/main.go）要导入 internal/service，写法只能是：import "example.com/myapp/internal/service"，不是 import "../internal/service"，也不是 import "./internal/service"。
Go 不支持相对路径 import，所有路径都是从模块根开始的绝对路径。这个字符串就是模块的“身份”，改错一个字符，整个项目编译失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 模块名在
go mod init时定死，后续所有import、CI 构建、IDE 跳转、文档链接都依赖它 - 如果模块名用了
my-app，但 import 写成my_app，会报cannot find module providing package - 本地开发时，路径拼错不会立刻暴露；等推到 CI 或换机器构建，
go build才崩
子命令入口（如 cmd/cli）不需要自己的 go.mod，但需要正确组织
cmd/ 下每个子目录对应一个可执行程序，例如 cmd/cli 和 cmd/api，它们共享同一个根模块，各自放一个 main.go 即可。构建时用 go build -o cli ./cmd/cli，工具链自动识别包路径。
容易踩的坑是把 cmd/cli/main.go 里的 package main 错写成 package cli，或漏掉 func main() —— 这会导致 go build 不报错但生成空二进制，运行时提示 exec format error 或直接退出。
-
cmd/目录下禁止放非main包；否则go build ./cmd/cli可能静默成功，但不生成可执行文件 - 多个 cmd 入口共用同一套依赖，
go mod tidy会统一拉取并记录在根go.mod中 - 不要在
cmd/cli里再go mod init，那会创建第二个模块，切断与根模块的关联
多层嵌套子目录（如 internal/user/repo）无需额外初始化
Go 的模块系统不关心目录深度，只认 import 路径和 go.mod 位置。只要 internal/user/repo/user.go 文件顶部声明 package repo，且被其他文件以 import "example.com/myapp/internal/user/repo" 引入，就完全合法。
真正的约束来自 Go 编译器：放在 internal/ 下的包，外部模块无法 import；但模块内部任意深度的子目录，只要路径对、包名不冲突，就能正常编译。
-
internal/是语义边界，不是物理限制；它不阻止你建internal/a/b/c/d/e，只要逻辑合理 - 别为了“看起来规范”而硬加空目录或占位文件；Go 不需要
internal/user/repo/go.mod - 重构时移动子目录（如把
internal/user改成internal/account），必须同步改所有 import 语句，否则编译失败
