应通过go111module=on禁用隐式模块创建、显式指定语义化版本、提交go.sum并禁用gosumdb=off来阻止未授权模块参与构建；goprivate仅用于私有模块隔离，不可滥用。
go get 时如何阻止自动拉取未授权模块
默认情况下，go get 会从 GOPROXY（如 https://proxy.golang.org）下载模块，而该代理不校验作者身份或包内容。只要模块路径合法、版本存在，就会被拉取并参与构建——哪怕它来自钓鱼仓库或已被篡改。
真正起效的防线不是“禁止下载”，而是“拒绝使用”。Go 的设计逻辑是：模块只有在 go.mod 中被 require 或由 go mod tidy 自动补全后，才会进入构建依赖树。所以关键控制点在模块声明环节。
- 禁用自动依赖推导：设置
GO111MODULE=on（确保始终启用模块模式），并避免在未初始化模块的目录下运行go build—— 否则 Go 可能尝试隐式创建go.mod并拉取未知依赖 - 禁止模糊版本：不用
@latest、@master或无版本号的go get github.com/user/pkg；必须显式指定语义化版本，例如go get github.com/user/pkg@v1.2.3 - 提前锁定可信源：对所有第三方依赖，在
go.mod中手动写入require行，并立即执行go mod tidy—— 这样后续构建只认go.sum里已记录的哈希，不会接受任何新版本或新模块
如何让 go build 拒绝未经校验的模块
go build 本身不联网，但它会检查 go.sum 是否包含所用模块的完整校验和。如果某模块缺失校验和，或校验和不匹配，构建会直接失败（自 Go 1.16 起默认行为）。这是防止“悄悄替换依赖”的核心机制。
但前提是：go.sum 必须被提交到版本库，且不能被绕过。
- 永远不要
git ignorego.sum—— 它不是临时文件，而是构建契约的一部分 - CI 环境中禁用
GOSUMDB=off：这个设置会跳过校验和验证，等同于关闭安全闸门 - 避免
go mod download -x或手动修改go.sum：校验和应仅由go mod tidy或go build自动生成和更新 - 若需临时调试私有模块，用
replace指令而非修改go.sum—— 替换后的模块仍受原go.sum条目约束（除非你同时go mod tidy）
GOPRIVATE 怎么防止私有模块被代理污染
当模块路径匹配 GOPRIVATE 模式（如 git.internal.company.com/*）时，Go 会跳过代理和校验和数据库，直接从 Git 服务器拉取。这看似“放行”，实则是为私有模块建立独立信任域——它把风险从“不可信代理”转移到“可控 Git 服务”。
真正危险的是混用：比如把 github.com/untrusted/pkg 错误地加入 GOPRIVATE，就等于主动关闭对该模块的校验。
- 设置方式：
export GOPRIVATE="git.internal.company.com/*,gitea.myorg.dev/*"（多个用逗号分隔，支持通配符） - 绝不将公共域名（如
github.com、golang.org）加入GOPRIVATE—— 这会让所有 GitHub 项目绕过GOSUMDB校验 - 确认生效：
go env GOPRIVATE查看当前值；再运行go list -m all | grep -E "(github|golang)"，若输出中对应模块显示// indirect且无校验和警告，说明未被代理劫持
为什么 replace 不是安全兜底方案
replace 常被当作“用本地代码覆盖远程恶意包”的解法，但它只影响构建时的源码路径，不改变 go.sum 中原始模块的校验和记录。也就是说，只要你没运行 go mod tidy，那个被替换的模块依然保留在依赖树里——只是源码被替换了，它的传递依赖、版本约束、甚至潜在的 init() 函数仍可能被加载。
- 正确做法：先用
replace指向可信 fork，再立刻执行go mod tidy—— 此时 Go 会重新计算整个依赖树，并把 fork 的校验和写入go.sum - 风险点：如果被替换的模块本身有
replace指令指向其他恶意模块，这些嵌套替换不会被自动展开，需要人工审计 - 更稳妥的替代：用
exclude彻底移除问题模块（需确认无其他依赖强依赖它），再通过require显式引入修复版
最易被忽略的一点：模块校验和不是防“下载”，而是防“替换”。只要 go.sum 在，哪怕你手动删掉 $GOPATH/pkg/mod 下的缓存，重新 go build 时也会严格比对网络下载内容的哈希——这才是 Go 依赖安全的底层锚点。
