go get 不加约束会拉入大量间接依赖，抬高内存基线；应通过 go mod graph 分析依赖树、replace 锁定精简版本、blank import 控制驱动加载、internal 包隔离框架初始化副作用。
go get 不加约束会拉进大量间接依赖，直接抬高内存基线
很多项目一引入 gin 或 echo 就发现启动内存涨了一倍，不是框架本身重，而是 go get 默认把所有 transitive dependency 全拉进来——比如 gin 依赖 golang.org/x/net，后者又带进来 golang.org/x/sys、golang.org/x/text 等十几个包，哪怕你只用了一个路由函数。
关键点在于：go get github.com/gin-gonic/gin 不会只下载 gin，它会解析整个依赖树并写入 go.mod，而 go mod tidy 又默认保留所有“可能被用到”的间接依赖（标记为 // indirect）。
- 验证方式：运行
go list -m all | wc -l，对比加框架前后的模块总数 - 真正被代码 import 的包，
go mod graph能看出哪些是叶子节点（无下游引用），哪些是悬空的 - 不要依赖
go mod tidy自动清理——它只删“未被 import 的直接依赖”，对间接依赖保守保留
用 replace + blank import 主动剪枝不使用的子模块
某些框架（如 gorm）默认加载全部数据库驱动，但你只用 PostgreSQL，其余 MySQL/SQLite 的驱动代码仍会被编译进去，增加二进制体积和初始化内存开销。
解决思路不是删掉 gorm，而是切断不需要的导入链：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在
main.go顶部加_ "gorm.io/driver/postgres"，删掉其他 driver 的 blank import - 在
go.mod中用replace gorm.io/gorm => ./internal/forked-gorm，然后在本地 fork 中删掉无关 driver 的 init 函数和注册逻辑 - 更轻量的做法：用
replace golang.org/x/net => golang.org/x/net@v0.25.0锁定一个已知精简版本（新版常新增 diagnostic 包，含大量反射和调试结构体）
避免 go get -u，防止语义化版本升级引入高开销组件
go get -u 是内存膨胀的隐形推手。比如 logrus v1.9 升级到 v1.10 后，默认启用 sync.Pool 缓存格式化器，但若你的日志量小，这个池反而增加 GC 压力；zap v1.24 引入了新的采样器，即使没开启采样功能，相关结构体也会被初始化。
- 升级前先查 CHANGELOG，重点看 “memory usage”、“allocations”、“init overhead” 相关条目
- 锁定版本：用
go get github.com/sirupsen/logrus@v1.9.3，而非go get -u - 降级时注意
go.sum校验失败——这不是 bug，是 Go 拒绝加载已被篡改的旧版本，此时应go clean -modcache再重试
internal 包 + 接口隔离，让框架代码无法触发冗余初始化
框架常在 init() 函数里预分配缓冲区、启动 goroutine、加载配置，这些动作只要包被 import 就发生。而 Go 不允许跨 module 控制 init 执行时机，唯一可靠办法是不让它被 import。
做法是把框架使用收口到 internal/http 这类目录下，并对外只暴露 interface：
- 定义
type Router interface { GET(string, func(http.ResponseWriter, *http.Request)) } -
internal/http/gin_router.go实现该接口，但外部pkg或cmd层只 import 自己的 interface，不 importgithub.com/gin-gonic/gin - 这样即使 gin 的
init()有副作用，也只在internal包构建时触发，且不会污染主模块的依赖图
真正的难点不在语法，而在重构路径——一旦框架代码散落在多个 main 文件或 handler 里，剪枝就变成一场全局 grep 和 import 重定向的体力活。
