go.mod中require分两组是因为Go自动推导依赖关系：第一组是代码中import且有合法go.mod的直接依赖，第二组是未被import但被依赖链引入、标记为//indirect的间接依赖，二者结构隔离便于识别污染源。
go.mod 里 require 块为什么分两组？
因为 Go 不靠人肉判断依赖关系，而是靠 import 语句 + 模块元数据自动推导。第一组是项目源码中 import 过的包（且其所在模块有合法 go.mod），第二组是那些没被直接 import、但被依赖链拖进来的包——它们被标记为 // indirect，并集中放在第二个 require 块里。
常见错误现象：go mod tidy 后突然多出十几行带 // indirect 的条目；或者本地 go run . 成功，CI 上却报 undefined: xxx —— 很可能就是某个间接依赖的版本在不同环境里被推导出不同结果。
- 直接依赖必须出现在至少一个
.go文件的import列表中 - 间接依赖不会出现在任何
import中，但它的存在影响构建结果（比如某函数签名由它提供） - Go 不会把间接依赖“合并”进第一个
require块，这是有意为之的结构隔离，方便识别污染源
什么情况下间接依赖会带上 // indirect 标记？
两种典型场景：一是你依赖的某个模块（比如 github.com/gin-gonic/gin）自己没写 go.mod，那它用的所有包都会被 Go 当作“无主依赖”，统统标为 // indirect；二是你依赖的模块虽有 go.mod，但它声明的依赖在你的项目里根本没被 import，Go 就把它降级为间接依赖。
使用场景举例：你只 import "github.com/go-sql-driver/mysql"，但 mysql 包内部用了 golang.org/x/sys，而你代码里没碰过 x/sys —— 那么 golang.org/x/sys 就会被列为 // indirect。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
go mod graph | grep golang.org/x/sys可查清谁引入了它 - 若该包版本老旧导致 panic，不能直接删
// indirect行——删了go mod tidy会立刻加回来，还可能选错版本 - 想升级？得用
go get golang.org/x/sys@latest，让它变成显式依赖并脱离// indirect
为什么不能手动删掉 // indirect 行？
这些行不是注释，是 Go 构建系统强制需要的锁定信息。// indirect 不代表“可有可无”，它参与 go build、go test 和 go list -m all 的完整依赖解析。删掉后，下次 go mod tidy 不仅会补上，还可能因缺少上下文而选错版本（比如挑了个不兼容的 pre-release 版本）。
性能影响：间接依赖越多，go mod graph 输出越长，go list -m all 执行越慢；但对实际构建耗时影响极小——Go 已缓存所有模块到 $GOPATH/pkg/mod。
-
go mod why -m github.com/some/pkg能告诉你为什么这个包被拉进来（哪怕它标着// indirect） - 如果某个
// indirect包其实已被上游修复废弃，应先确认是否还有其他依赖链指向它，再用exclude处理，而非删除 - 伪版本（如
v0.0.0-20230101000000-abcdef123456）常出现在// indirect中，说明对应模块没发正式 tag
module 路径和 import 路径不一致时，依赖怎么算直接还是间接？
Go 只认 import 语句里的字符串，不认 module 声明。比如你在 go.mod 里写 module example.com/myapp，但代码里 import "github.com/user/lib"，那 github.com/user/lib 就是直接依赖——哪怕它跟 example.com/myapp 完全无关。
容易踩的坑：有人把本地调试用的 replace 当成“临时依赖”，结果忘了删，导致 CI 环境因找不到替换路径而失败；还有人误以为 replace 能让某个包变成直接依赖，其实它只是重定向源，不影响 import 关系判定。
- 直接依赖的版本由你控制（
go get或手动改go.mod），间接依赖的版本由直接依赖的go.mod锁定 - 如果上游模块删掉了某个间接依赖，而你的项目又恰好用到了那个包的符号，就会触发
imported and not used或undefined错误 - 真正关键的不是“有没有
// indirect”，而是“这个包是否在构建时被实际加载”——go list -f '{{.Dir}}' -m github.com/xxx/yyy可验证它是否真进了构建路径
go.mod 约束，也受整个模块图的最小版本选择算法（MVS）影响，而 MVS 在遇到多个路径引入同一包不同版本时，行为并不总是直觉可预测。 
