go模块无法真正跳过不常用依赖下载，核心在于清理、隔离和按需触发：go mod tidy按import图静态删除未引用模块；replace可屏蔽依赖；build tag+条件import实现更干净隔离；隐性依赖需通过go build -a -v验证。
不能真正“跳过”不常用的模块依赖下载，Go 的模块系统不会因你没显式 import 就忽略某个 require 行——只要它在 go.mod 里，go mod download 或构建时就可能拉取。所谓“跳过”，其实是控制哪些模块被纳入下载范围，核心在于清理、隔离和按需触发。
go mod tidy 能删掉哪些“不常用”的依赖
go mod tidy 不是按“使用频率”删模块，而是按“是否被 import 图引用”做静态判断。它只移除三类模块：
- 代码里完全没
import的包（哪怕你写过又删了，但go.mod没同步） - 不是任何现存依赖的传递依赖（即没人 import 它）
- 没被
replace、exclude或显式require锁定
常见误操作：改了代码删掉某个 import，但没跑 go mod tidy，结果 go.mod 里还留着那行 require，后续 go mod download 仍会下它。
用 replace 指向空目录或 stub 模块来“屏蔽”依赖
某些 SDK 或工具库（比如带 cgo 或特定 build tag 的监控模块）你只在 CI 或特定环境用，本地开发想跳过下载？可以用 replace 把它指向一个最小化 stub 模块：
- 建个空目录
./stub/xxx，里面只放一个合法go.mod（内容：module stub/xxx） - 在项目
go.mod末尾加：replace github.com/real/xxx => ./stub/xxx -
go mod tidy会接受这个替换，之后所有对该路径的解析都走本地，不再联网
注意：replace 不影响 go list -m all 输出，但 go mod download 真的不会去抓被 replace 的远程模块。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
build tag + 条件 import 是更干净的隔离方式
如果某个依赖只用于测试或特定平台（如 Windows GUI、嵌入式驱动），别让它进主依赖树：
- 把相关代码放进单独文件，文件头加
//go:build windows或//go:build integration - 对应
import放在这类文件里，而非主逻辑 -
go mod tidy默认只扫描启用的 build tag 组合，所以未匹配的import不会被计入依赖图
验证方法：运行 go list -m all，确认该模块没出现在输出里；再试 go mod download，它就不会碰这个包。
离线构建时最容易被忽略的隐性依赖
你以为删干净了，结果 go build 还是去拉模块？往往是因为：
-
//go:embed引用的文件路径匹配了某个模块名（比如 embed "github.com/foo/bar"） - cgo 启用后，
CFLAGS或 pkg-config 查找触发了间接依赖 - 某个
indirect依赖被其他包动态 import（如通过plugin.Open或反射加载）
这类依赖不会出现在 go list -m all 的默认输出里，只有实际运行时才暴露。真要离线，得结合 go build -a -v 观察完整 fetch 日志，而不是只信 go mod tidy 的结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
