go mod tidy 会递归拉取所有间接依赖导致构建慢、二进制膨胀和安全告警增多；应通过 go list -m all 和 go mod graph 定位幽灵依赖，用 //go:build、replace、-tags 等手段精简；ugorji/go 需按需启用 codec 格式并禁用 fastpath；gomaxprocs 应适配 cgroup 限制而非宿主机核数；sync.pool 仅适用于固定结构、短生命周期对象且必须 reset/put 规范使用。
go mod tidy 会偷偷拉取大量间接依赖
执行 go mod tidy 时，Go 会递归解析所有 transitive 依赖，并把它们写进 go.mod。哪怕你只用了一个函数，只要它的模块依赖了 logrus、cobra、gRPC 等重型库，这些都会被引入——最终导致构建慢、二进制膨胀、安全扫描告警激增。
- 运行
go list -m all | wc -l查看当前实际加载的模块数，超 200 个就该警惕 - 用
go mod graph | grep -v 'your-module-name' | head -20快速定位“幽灵依赖”来源 - 禁用不需要的依赖：在
go.mod顶部加//go:build !unused_deps，再用-tags unused_deps构建，可跳过部分 init 块加载 - 对非核心模块（如 CLI 工具类）用
replace指向最小化 fork 或空实现，避免拖入完整生态
ugorji/go 这类 Codec 库默认吃掉 900KB 二进制
它把 MsgPack/CBOR/JSON/Proto 所有编解码器全编进去，哪怕你只用 codec.MsgpackHandle。不干预的话，go build 会链接全部符号，体积和启动耗时都不可控。
- 只启用需要的格式：构建时加
-tags "codec.msgpack"，其他格式代码不会进入二进制 - 禁用 fastpath 可减 200KB：
-tags "codec.notfastpath"，性能损失约 10%，但对大多数 HTTP API 足够 - 别同时用
codec.noswissmap和codec.notfastpath——后者已隐含前者，重复加没效果还可能触发未定义行为 - 验证是否生效：
go tool objdump -s "github.com/ugorji/go/codec.*Unmarshal" your-binary，输出为空说明裁剪成功
runtime.GOMAXPROCS 设置错误会让调度器空转
设太高不是“更并发”，而是让调度器频繁切换 P、争抢全局队列、增加 atomic 操作开销。尤其在容器里，runtime.NumCPU() 返回的是宿主机核数，不是 cgroup 限制值。
- 查真实配额：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us，若前者为 -1 则不限制；否则除一下得可用核数 - I/O 密集型服务（HTTP handler、DB client）设
runtime.GOMAXPROCS(1)反而更稳——netpoller 不吃多 P - CPU 密集型任务（如图像转码）设 4–16 即可，再高
pprof里会看到runtime.schedule占比异常升高 - 别用环境变量
GOMAXPROCS覆盖——它在init阶段就生效，早于你的main，无法动态适配 cgroup
sync.Pool 复用不当反而加重 GC 压力
Pool 不是万能缓存，对象生命周期混乱或大小不一，会导致内存碎片、逃逸分析失败、甚至比直接 new 更慢。
- 只缓存固定结构、短生命周期、创建开销大的对象（如
*bytes.Buffer、json.Decoder） - 每次
Get后必须Reset()，否则残留数据引发逻辑错误；Put前确保对象没被 goroutine 持有引用 - 避免缓存含指针字段的 struct——Pool 释放时不清零，GC 会扫描整个对象图
- 上线前跑
go run -gcflags="-m" your_file.go确认关键对象没逃逸到堆上
go build -ldflags="-s -w" 是压不住的。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
