go mod init 后不能在子目录再建 go.mod，因为 go 不支持嵌套模块，go.mod 是模块边界的唯一标识，每个模块路径必须全局唯一；子目录新建 go.mod 会导致构建报错、包识别失败和依赖冲突。
go mod init 后为什么不能在子目录再建 go.mod
Go 工具链不支持“嵌套模块”，go.mod 是模块边界的唯一标识，且每个模块路径（如 github.com/user/project）必须全局唯一。你在 internal/service 下手动 go mod init github.com/user/project/internal/service，会导致：go build 报错 main module does not contain package；go list ./... 无法识别包归属；依赖解析时出现版本冲突或 fallback 到老版本。
真正需要“多模块”时，只有一种合规路径：拆成独立 Git 仓库 + 独立 go.mod + 语义化版本号（如 v1.2.0），再通过 require 引入主项目。日常开发中绝大多数分层需求，靠包（package）而非模块（module）解决。
internal/ 目录如何实现安全的分层隔离
internal/ 不是语法特性，而是 Go 编译器的导入限制机制：任何以 internal/ 开头的路径，只能被其父级或同级目录下的包 import。比如 internal/handler 可以 import internal/usecase，但 cmd/myapp 不能 import internal/handler —— 这个检查在 go build 阶段强制执行。
- 目录结构建议扁平，避免
internal/handler/v1/user这类过深嵌套；改用internal/user/handler或按职责切分internal/user/api、internal/user/core - 所有
internal/xxx包都属于顶层模块，import 路径为github.com/user/project/internal/xxx，无需额外go.mod - 禁止循环 import：例如
handler不能直接 importgateway，必须通过usecase定义的 interface 间接调用
pkg/ 和 internal/ 的边界怎么划
pkg/ 是显式对外暴露的公共能力层，internal/ 是封闭的业务实现层。区别不在代码风格，而在设计意图和维护承诺：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
pkg/logger要有稳定导出 API、完整文档、单元测试，且承诺向后兼容；别人go get github.com/user/project/pkg/logger应该能直接用 -
internal/logger可能只是临时封装，随时会重构甚至删除，外部根本 import 不进来 - 如果某个工具函数只被本项目
cmd/和internal/共享（比如配置加载、信号处理），放pkg/util比放internal/util更合理 —— 它本质是基础设施，不是业务逻辑
replace 怎么用才不踩坑
本地模块尚未发布到远程仓库时，用 replace 指令临时指向本地路径，是唯一安全做法。但它只在当前 go.mod 生效，且必须配合模块路径一致：
假设你拆出了 pkg/utils 模块，它的 go.mod 声明为 module github.com/user/project/pkg/utils，那么主项目的 go.mod 必须写：
replace github.com/user/project/pkg/utils => ./pkg/utils
常见错误：
- 路径写错：用
../pkg/utils或绝对路径，go build会失败 - 模块路径不匹配：
replace左侧必须和被替换模块的module声明完全一致（包括大小写） - CI 环境失效：
replace不会被go install或远程构建继承，上线前必须删掉或换为真实版本号
多层 replace 容易失控，超过两个就该考虑是否真需要拆模块 —— 大部分时候，一个顶层 go.mod + 清晰的 internal/ 分包已经足够。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
