go get默认绕过安全审查，仅校验go.mod合法性而不检查包来源、签名或漏洞；必须配合go111module=on、goprivate（跳过代理直连私有模块）和goproxy（多级fallback代理）协同管控，否则私有模块会因代理拦截导致401/404，且手动编辑go.mod将绕过路由逻辑引发未授权拉取。
为什么 go get 会绕过安全审查直接拉包
默认情况下，go get 只检查 go.mod 是否合法，不校验包来源、签名或已知漏洞。只要网络通、模块路径能解析，它就下载并写入 require 行——哪怕这个包已被 govulncheck 标记为高危，或作者早已弃更、被投毒。
用 GOPRIVATE + GOPROXY 强制分流管控
私有模块和公共模块必须走不同通道，否则代理会把内部 Git 地址当成公开地址去查，结果 401 或 404，还可能把错误日志暴露到 CI 日志里。
-
GO111MODULE=on是前提，否则所有模块行为退化为 GOPATH 模式，GOPRIVATE完全失效 -
go env -w GOPRIVATE="git.internal.company.com,github.com/myorg"：只对这些域名跳过代理，直连；支持通配符如*.corp.example.com -
go env -w GOPROXY=https://goproxy.cn,direct：逗号后必须跟direct，否则私有模块仍被代理拦截 - 验证命令：
go env GOPRIVATE和go env GOPROXY输出应非空且含预期值
CI 阶段拦截非法依赖的硬性检查
不能靠人自觉，得让构建失败来兜底。以下检查必须放在 go build 前执行：
-
go list -m all | grep -v '^\(std\|cmd\|internal\)' | sort -u：列出所有第三方模块，排除标准库 -
govulncheck -json ./... | jq -r '.Results[]?.Vulnerabilities[]?.ID'：输出任意已知 CVE ID 就立即exit 1 -
grep -q 'github.com/malicious/' go.sum：对明确黑名单域名做字面匹配（需维护组织级黑名单） - 禁止
replace出现在go.mod中未备案的路径——CI 可用go mod edit -json | jq '.Replace[]?.New.Path'提取并比对白名单
go.mod 不该被手动编辑，但开发者总想“抄近路”
有人会直接改 go.mod 加一行 require github.com/bad/pkg v0.1.0，以为这样就能跳过 go get 流程。实际后果是：
-
go mod tidy下次运行时会删掉这行——因为没对应 import，Go 认为它是“幽灵依赖” - 但
go build仍可能成功（如果该包已被缓存），造成侥幸心理 - 真正危险的是：这种手动写法绕过了
GOPROXY和GOPRIVATE的路由逻辑，可能触发未授权的直连拉取
最有效的约束不是教育，而是让 git commit 前的 pre-commit hook 自动运行 go mod tidy && git diff --exit-code go.mod go.sum —— 任何未通过 tidy 同步的修改直接拒绝提交。
