go mod tidy会拉入未直接import的包，因为go模块依赖具有传递性，它递归解析所有间接依赖并应用最小版本选择策略以构建可复现的依赖图。
为什么 go mod tidy 会拉进你没直接 import 的包
因为 Go 模块依赖是传递的，go mod tidy 不只看你的 import 语句，还会递归解析所有依赖的依赖。比如你 import "github.com/gin-gonic/gin"，而 gin 内部用了 golang.org/x/net/http2 和 github.com/go-playground/validator/v10，这些就会被自动写入 go.mod。
这不是 bug，是设计使然：Go Modules 默认采用「最小版本选择（MVS）」策略，目标是构建可复现、无冲突的依赖图。但副作用是——你可能在 go.sum 里看到几十个从未手动引入的模块哈希。
- 真正影响编译和运行的是最终依赖图，不是你写了哪些
import -
go mod graph可以可视化整个传递链，帮你定位“谁带进了这个包” - 如果某个间接依赖引发兼容性问题（比如用了不支持的 Go 版本），得用
replace或升级上游模块来解决，而非删掉它
微模块（micro-module）不是目录拆分，而是语义隔离
很多人把“建一堆子目录 + 每个目录放一个 go.mod”当成微模块，这是常见误解。真正的微模块关键不在物理结构，而在 module path 的独立性和发布契约。
例如：github.com/yourorg/auth 和 github.com/yourorg/payment 是两个微模块，它们各自有独立的 go.mod、版本号（v1.2.0）、go.sum，且能被其他项目单独 go get。而 github.com/yourorg/backend/internal/auth 这种只是内部包，没有独立 module path，不算微模块。
- 微模块必须对外暴露清晰的 API 边界（通常通过
pkg/下的导出接口） - 它的
go.mod里不能含replace指向本地路径（否则破坏可复现性） - CI 中需为每个微模块单独跑
go test ./...和go build -o ./bin/...，不能共享构建上下文
模块依赖与微模块共存时最容易踩的坑
当主项目同时依赖多个微模块，又在本地开发时频繁修改它们，replace 指令很容易失控。典型错误是：在主项目的 go.mod 里写了一堆 replace github.com/yourorg/auth => ../auth，但忘了在 CI 环境中移除，导致构建失败或行为不一致。
- 本地开发建议用
go work init+go work use管理多模块工作区，比一堆replace更安全 - 微模块的版本号必须真实发布（打 tag），不能靠伪版本（
v0.0.0-xxx）长期交付，否则下游无法锁定 - 如果两个微模块都依赖同一个底层库（如
github.com/sirupsen/logrus），但要求不同主版本（v1 vs v2），Go 不会自动做适配——这是语义化版本不兼容的硬边界，必须由微模块自己降级或迁移
什么时候该拆微模块，而不是加新包
判断标准不是代码量或功能复杂度，而是「是否需要独立演进、独立发布、被多个项目复用」。比如一个通用的 JWT 解析工具，如果被 auth、api-gateway、cli 工具三个项目共用，且各自对它的更新节奏、breaking change 接受度不同，那就该抽成微模块。
- 拆之前先确认：它有没有自己的测试集、文档、变更日志？是否已发布到公开或私有 proxy？
- 避免过早拆分：初期共用
internal/pkg/jwt完全合理；等出现第一个外部调用方再拆，成本最低 - 微模块一旦发布，它的
go.mod就成了契约——改require版本可能触发下游go mod tidy失败，这点比普通包严格得多
cmd/ 直接 import internal/ 下的微模块实现细节。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
