Go不支持物理嵌套go.mod，仅识别向上最近的一个；多模块需用replace或go work显式桥接；internal仅作导入路径校验，不创建新模块；error嵌套宜控制在3–4层内。
Go 不支持物理嵌套的 go.mod 文件
你不能在子目录里放一个 go.mod，然后指望它被主模块“自动识别”或“继承式加载”。Go 工具链只认当前构建路径向上最近的那个 go.mod，其他一概无视。强行加会导致：main module does not contain package、no required module provides package 这类错误。
常见误操作：在 cmd/ 或 internal/service 下运行 go mod init，结果整个项目 build 失败。这不是 bug，是设计使然——模块边界必须显式声明且唯一。
- 每个
go.mod对应一个独立可发布的模块，路径（如github.com/user/project）就是它的身份标识 - 同一 Git 仓库内多个
go.mod是合法的，但它们互不隶属；必须靠replace或go work显式桥接 -
go build ./...只会扫描当前模块下的所有包，不会跨go.mod边界找代码
多模块协作必须用 replace 或 go work
想让主模块引用本地子模块（比如 ./pkg/core），不能靠目录结构“猜”，得明说。最常用的是 replace 指令：
在主模块的 go.mod 里写：replace github.com/user/core => ./pkg/core，然后跑 go mod tidy。这时 go list -m all 会显示该模块后缀带 => ./pkg/core，表示生效。
立即学习“go语言免费学习笔记（深入）”；
-
replace是开发期技巧，发布前必须删掉，否则 CI 构建会失败 -
go work更适合长期多模块联调：根目录下go work init ./ ./pkg/core，之后所有命令都在 workspace 上下文中执行 - 两者都不改变 import 路径——你的代码仍写
import "github.com/user/core"，只是源码来源被重定向了
internal 目录不是“嵌套模块”，而是模块内路径守门员
internal 的作用和嵌套层级完全无关。它不创造新模块，也不影响依赖解析；它只是编译器在 import 阶段做的一次路径校验：如果 A 包 import 了 github.com/user/repo/internal/util，那 A 的 import 路径必须以 github.com/user/repo 开头，否则报错 use of internal package not allowed。
- 同一模块内，
cmd/server和internal/util可以自由互相 import，哪怕隔着五层目录 - fork 到
github.com/other/fork后，原internal就不可用了——因为模块路径前缀变了 - CI 构建失败但本地 OK？大概率是工作目录路径和
go.mod中声明的 module 路径不匹配，导致模块根计算错误
嵌套过深的 error 包裹会拖慢日志和 panic traceback
Go 允许无限嵌套 fmt.Errorf(": %w", err)，但实际中超过 3–4 层就该警惕了。问题不在语法限制，而在可观测性和内存开销：
- 每层包裹都新建一个
error实例，高频路径下会增加 GC 压力 - panic 日志里出现重复短语（如
failed to parse: failed to parse: failed to parse）通常是同一 error 被反复包裹 - 调试时看到 8 层
caused by基本等于放弃溯源——人眼无法有效展开
真正需要的是语义清晰的错误分类 + 关键上下文透传，不是堆层数。用 errors.Is 和 errors.As 查类型，比数冒号更可靠。
模块层级本身没有硬性嵌套限制，但人为制造多层 go.mod、滥用 internal、无节制包裹 error，这三件事叠加起来，会让项目从可维护变成可抛弃。关键不是“能不能”，而是“值不值得”。
