结论：go build -tags 不影响 go.mod 中的 require 列表，也不跳过模块下载或解析，仅控制当前包内哪些 .go 文件参与编译；依赖模块是否被拉取取决于 go.mod 声明，而非 build tags。
编译标记（build tags）不是用来筛选模块依赖的
直接说结论：go build -tags 不影响 go.mod 中的 require 列表，也不会跳过某个模块的下载或解析。它只控制「当前包内哪些 .go 文件参与编译」，对依赖模块本身无过滤作用。如果你期望通过 -tags 让 github.com/example/feature 这个模块不被拉取或不被构建，那是做不到的。
常见误解场景：开发者在 main.go 里写了 // +build prod，以为加上 go build -tags=prod 就能避开 dev-only 的依赖模块——但只要该模块出现在 go.mod 的 require 行中，go build 仍会解析、校验、甚至下载它（哪怕其代码完全没被引用）。
想让某个模块“有条件地存在”，必须用 replace + build tag 组合
真正可行的方案是：把该模块的引入写在带构建约束的文件里，并配合 replace 指令做条件性重定向。典型做法如下：
- 新建一个
feat_enabled.go，顶部加// +build feature（注意空行），里面 import 目标模块，比如import _ "github.com/example/feature" - 再建一个
feat_disabled.go，顶部加// +build !feature，内容为空或仅声明 stub 接口 - 在
go.mod中仍保留require github.com/example/feature v1.2.0（否则go build -tags=feature会报错找不到包） - 若想彻底避免非必要模块被下载，可用
replace github.com/example/feature => ./stub/feature，并在./stub/feature下提供最小化兼容实现
这样，go build -tags=feature 才会实际加载真实模块；而 go build -tags=（不传 tag）时，feat_enabled.go 被忽略，feat_disabled.go 生效，且 replace 可防止真实模块被意外触发下载。
go.sum 和 go list 会暴露“隐藏”依赖的真实存在
即使你用构建约束让某段代码不编译，只要模块出现在 go.mod 中，它就一定会出现在 go.sum 里，也会被 go list -m all 列出。这不是 bug，而是 Go 模块语义的一部分：依赖图是静态声明的，与构建时是否用到无关。
验证方式：
- 运行
go list -f '{{.Deps}}' .查看当前包实际依赖项（受 build tag 影响） - 运行
go list -m all查看所有声明的模块（不受 build tag 影响） - 检查
go.sum是否包含目标模块哈希——如果有，说明它已被纳入模块图
这意味着 CI 构建时若使用 go mod download 或 go mod verify，所有 require 条目都会被处理，不管 build tag 如何设置。
替代方案：按环境拆分 go.mod 更可靠
如果某些模块只应在特定环境（如测试、CI、本地调试）中存在，最干净的做法是拆出独立的 go.mod 文件，例如：
-
go.mod（主应用，不含敏感/重型依赖） -
internal/testutil/go.mod（仅供测试，含require github.com/stretchr/testify等） -
cmd/devserver/go.mod（本地开发服务，含require github.com/fsnotify/fsnotify）
这样每个子模块可独立管理依赖，go build ./cmd/devserver 只会拉取对应 go.mod 的依赖，不会污染主构建。缺点是需手动维护多份 go.mod，但比靠 build tag “假装没引用”更透明、更可控。
build tag 的边界很窄：它只管文件级编译开关，不负责依赖裁剪。真要控制模块粒度，得回到模块划分和 replace / exclude 的组合上——而后者一旦用错，go build 可能静默失败或版本冲突，比编译错误更难排查。
