Go服务高并发下依赖膨胀会拖慢启动、增内存、致冷启动延迟甚至init死锁；需用go list和go mod graph识别伪依赖，替换重型库为轻量方案，慎用replace/exclude，通过build tags裁剪调试依赖，并清理go.sum。
Go 服务在高并发场景下，模块依赖膨胀会直接拖慢启动速度、增大内存占用、延长冷启动时间，甚至引发 init 阶段死锁或竞态——这不是理论风险，而是线上真实发生的故障源头。
如何快速识别“伪依赖”和隐式间接依赖
很多 go.mod 里列出的模块，实际代码中根本没被引用，只是因为某个依赖包的 go.mod 声明了它，就被 go mod tidy 自动拉进来。这类“幽灵依赖”在微服务拆分频繁的团队里尤其多。
- 用
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | sort -u列出所有被显式 import 的路径，再和go list -m all对比，差集就是可疑项 - 重点关注带
_test后缀的模块（如golang.org/x/tools/cmd/stringer），它们常因测试工具被误引入生产依赖 - 运行
go mod graph | grep 'your-module-name'查看谁在拉你、你又在拉谁，特别注意那些只在replace或//go:build ignore文件里出现的依赖
替换 heavy 依赖：json、http、uuid 的轻量替代方案
像 github.com/go-playground/validator/v10、github.com/gorilla/mux、github.com/satori/go.uuid 这类库，功能全但启动开销大，且常自带大量未使用子包，在高并发短生命周期服务（如 Serverless、边缘网关）中尤为明显。
- JSON 解析优先用标准库
encoding/json；若需 tag 支持更灵活，选github.com/tidwall/gjson（零分配解析）或github.com/mitchellh/mapstructure（仅结构体映射，无反射注册） - HTTP 路由放弃
gorilla/mux，改用net/http.ServeMux+http.StripPrefix组合，或极简第三方如github.com/go-chi/chi/v5（注意只import "github.com/go-chi/chi/v5"，别带chi/middleware等非必需子包） - UUID 生成不用
satori/go.uuid（已归档）或google/uuid（含 rand.Reader 初始化开销），改用github.com/segmentio/ksuid（时间有序、无全局状态）或直接crypto/rand.Read+ base64 编码
go.mod 中 replace 和 exclude 的慎用边界
replace 看似能强制降级或跳过问题模块，但极易破坏依赖图一致性；exclude 更危险——它会让 Go 工具链“假装某版本不存在”，一旦其他依赖暗地里 require 它，构建就会失败或行为异常。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 仅在以下情况用
replace：replace golang.org/x/net => golang.org/x/net v0.12.0（修复 CVE 且上游未合入），且必须同步验证所有依赖该模块的子包是否兼容 -
exclude几乎不该出现在生产服务的go.mod中；若真要排除（比如某模块含init()且无法修改），优先考虑用//go:build !exclude_xxx+ 构建标签隔离，而非全局 exclude - 所有
replace必须加注释说明原因、影响范围和回退方式，例如：// replace to avoid init-time http.DefaultClient setup in v1.18.0 (see issue #xxx)
构建时裁剪：用 build tags 和 go:linkname 控制符号可见性
有些模块只在调试或本地开发时需要（如 pprof、expvar、pprof-server），上线后应彻底剥离，而不是靠 runtime 条件判断——那部分代码仍会进二进制、占内存、触发 init。
- 把调试相关逻辑放进
debug.go，开头加//go:build debug，构建时用go build -tags=debug显式启用 - 对必须保留但可延迟初始化的模块（如日志 hook、metric reporter），用
sync.Once包裹初始化逻辑，避免init()阶段执行 - 极端场景下，可用
go:linkname手动屏蔽符号（如隐藏net/http/pprof.init），但仅限内部 infra 工具链，不建议业务服务使用
依赖瘦身不是删得越狠越好，关键是让每个模块的存在都有明确、可观测的理由。最常被忽略的一点是：go.sum 文件里的校验和，一旦你手动删掉某个模块，却没清理对应行，下次 go mod tidy 可能静默恢复它——检查 go.sum 应该成为每次依赖调整后的必检步骤。
