Go不支持包名黑名单，真正可控的是路径匹配+代理跳过+替换/排除策略；因模块系统无exclude_package语法，所有规避必须基于模块路径，依赖GOPRIVATE、replace或exclude实现。
不能靠“黑名单”规避模块下载，Go 没提供全局包级黑名单机制；真正可控的是路径匹配 + 代理跳过 + 替换/排除策略。
为什么不存在真正的“黑名单包”功能
Go 的模块系统不支持类似 npm ignore 或 pip exclude 那样的声明式包名黑名单。go.mod 中没有 exclude_package "github.com/bad/pkg" 这类语法。所有“规避”行为都必须落在具体路径上，且依赖于 Go 的模块解析规则：匹配 GOPRIVATE、触发 replace、或利用 exclude（仅对特定 module path 生效）。
-
exclude只能写在当前项目的go.mod里，且只对指定 module path + version 生效，无法通配或按包名模糊匹配 - 试图用
replace github.com/bad/pkg => /dev/null会失败：Go 不接受无效路径，且replace必须指向合法目录或远程模块 - 删掉
go.sum或清空pkg/mod只是临时清除缓存，下次go build仍会按需拉取——除非你已切断其被引入的路径
真正有效的三类规避路径
不是封包名，而是截断模块路径的解析链。以下策略按优先级和稳定性排序：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
用
GOPRIVATE跳过代理与校验：对私有或高风险域名（如git.internal.company.com、github.com/untrusted-org），设go env -w GOPRIVATE=git.internal.company.com,github.com/untrusted-org。这样 Go 会直接走 Git 协议、跳过GOPROXY和GOSUMDB，你再配合 Git 凭据控制访问权限 -
用
replace强制重定向到安全副本：在go.mod中写replace github.com/bad/pkg => github.com/trusted-fork/pkg v1.2.3。这比exclude更可靠，因为它是主动替换而非被动忽略；注意版本号必须存在且可解析 -
用
exclude切断已知问题版本：仅当确认某 module path 的特定版本存在漏洞时使用，例如exclude github.com/vulnerable/lib v0.1.0。但必须搭配go mod tidy生效，且无法阻止该模块其他版本被间接引入
容易踩坑的“伪黑名单”操作
这些做法看似在屏蔽，实则无效或引发新问题：
立即学习“go语言免费学习笔记（深入）”；
- 在
go.mod里删掉require行却不运行go mod tidy：残留的go.sum条目可能让 Go 在构建时悄悄补回该模块 - 设
GOPROXY=direct但没配GOPRIVATE：Go 仍会尝试向proxy.golang.org查询未匹配GOPRIVATE的路径，导致超时或 404，而非跳过 - 用正则或字符串匹配在 CI 脚本里 grep 删除
go list -m all输出中的包名：这只是文本处理，不影响实际构建行为；Go 编译器完全无视你的 grep 结果 - 把
vendor/里的包手动删掉却不加-mod=vendor构建：Go 仍会从网络拉取缺失部分，vendor不是默认启用的离线模式
复杂点在于间接依赖的穿透性
即使你用 replace 或 exclude 控制了直接依赖，只要某个间接依赖（比如 A → B → C）硬编码引用了你想规避的包 C，而 B 又没做适配，你就无法单靠当前项目配置阻断它。这时必须：replace 掉 B 自己，或推动 B 升级依赖。没有银弹，只有路径级的逐层拦截。
