go clean -modcache 删除的是 $gomodcache（默认 $gopath/pkg/mod）中所有解压的模块源码、.zip 包及校验数据，但不删除项目 vendor/ 或 go.mod；删后磁盘空间未释放常因进程正占用文件，需关闭 ide 等再验证。
go clean -modcache 删的是什么，为什么删完还占着磁盘
它删的是 $GOMODCACHE（默认为 $GOPATH/pkg/mod）里所有解压后的模块源码、.zip 包和校验数据，但不会动你项目目录里的 vendor/ 或 go.mod。常见错误现象：执行 go clean -modcache 后 du -sh $(go env GOPATH)/pkg/mod 显示空间没变——因为 Linux/macOS 下，只要还有进程（如 VS Code 的 Go 插件、后台 go build）正打开这些文件，内核就不会真正释放磁盘块。
验证是否清干净：lsof +D $(go env GOPATH)/pkg/mod | wc -l 输出应为 0；否则先关掉 IDE、停掉构建脚本，再重试。
要立刻释放空间，可加一步：go build -a ./ 强制全量重编译，旧缓存文件句柄被新进程替换后自动回收。
go mod tidy 为什么删不掉“碎屑型”间接依赖
go mod tidy 只删完全断开引用链的模块，对高频但“隐性”使用的间接依赖无能为力。比如：
-
golang.org/x/sys被多个标准库包（os、net）间接拉入，即使你没import它，tidy也绝不会动 -
github.com/mattn/go-sqlite3若只在//go:build cgo分支下使用，而当前CGO_ENABLED=0，tidy默认忽略该路径，留着却不用 -
go list -deps显示它被引用，但实际运行时只在特定构建标签或测试中才激活，静态分析无法覆盖
这类模块不是 bug，是设计使然：Go 工具链必须保证任意合法构建组合都能成功，所以宁可多留，不可少删。
sync.Pool 里的对象不是“碎屑”，但用错会制造碎屑
sync.Pool 本身不产生内存碎片，但用法不当会让 GC 面临大量小对象清扫压力，间接加剧外部碎片。关键点：
- Put 前必须重置状态：
buf.Reset()、slice = slice[:0]，否则下次 Get 拿到脏数据，可能触发额外分配掩盖问题 - Pool 的
New函数别做耗时操作（如make([]byte, 1e6)），它在 Get 失败时同步调用，会卡住 goroutine - 高频短生命周期对象才适合放 Pool：HTTP header 缓冲、JSON 解析临时结构体；DB 连接、全局配置塞进去反而加重 GC 扫描负担
真正抗碎片的是预分配：用 make([]byte, 0, 1024) 而非 make([]byte, 0)，避免 append 频繁扩容产生 16B/32B/64B 散落空洞。
真正需要人工干预的碎屑场景
工具链管不了的部分，得靠人盯：
-
//go:embed引用的模块（如嵌入模板、SQL 文件）不会出现在 import 图里，tidy会误删，得手动加require并注释说明 -
import _ "github.com/lib/pq"这类空白导入，若其init()没副作用（比如没注册 driver），tidy会删，但你的database/sql.Open("postgres", ...)就直接 panic - CI 构建用了
GOOS=linux GOARCH=arm64，本地开发用darwin/amd64，两套缓存共存却不清理，$GOCACHE体积翻倍但利用率极低
高频调用产生的“碎屑”从来不在代码里，而在构建上下文、环境变量、IDE 行为和 GC 对象分布模式中——盯着 go env GOCACHE 和 go env GOPATH 的实际路径，比盯着 go.mod 更容易找到真问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
