发布Go模块需确保所有依赖可公开访问：module path必须与Git仓库地址严格一致，实验性依赖须打合法v*标签并推送，清除go.mod中replace行，避免@master或commit hash等不可靠引用，且所有require路径须能被任意下游通过标准协议解析。
发布模块时遇到未公开实验性依赖会直接失败
Go 的 go mod publish 不存在，发布 Golang 模块本质是推送到可被 go get 解析的 Git 仓库，并确保路径、认证、版本声明全部对齐。如果模块依赖了未公开（如内部 fork、临时分支、无 tag 的 commit）或实验性（如 github.com/org/lib@master 这类非语义化版本）的第三方代码，下游用户 go mod tidy 会卡在 unknown revision 或 module not found —— 不是因为你“没发布”，而是别人根本拉不到依赖。
实验性依赖必须转为稳定可寻址的形态才能对外发布
不能把 replace 留在最终发布的 go.mod 里，也不能依赖 @master 或 @latest 这种动态引用。真实可行的做法只有两条路：
- 给实验性依赖打一个明确 tag（哪怕叫
v0.0.0-dev.1），并确保该 tag 在对应 Git 仓库中存在且可公开访问； - 若依赖来自私有 fork，必须将 fork 公开（或至少设为内部可见），且
go.mod中的模块路径要与 fork 的 HTTPS/SSH 地址严格一致（例如github.com/your-org/logrus，而非原版github.com/sirupsen/logrus）； - 避免使用
go get github.com/x/y@abc123这类 commit hash 引用——它会被转成伪版本（如v0.0.0-20230101000000-abc123），但该 commit 必须存在于远程仓库的 ref 中，否则下游无法解析。
本地 replace 只用于开发，发布前必须清理
replace 是调试利器，但它是本地构建视角的覆盖规则，不参与模块分发逻辑。发布前检查：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 运行
go mod edit -dropreplace=xxx清除所有replace行； - 执行
go mod tidy并确认无报错，再跑一次go build ./...验证能否从干净环境构建； - 用
go list -m all | grep xxx确认实验性依赖实际解析到的是哪个路径和版本，是否仍指向本地或不可达地址。
GO_PRIVATE 和 GOPROXY 对发布端无影响，只作用于下游消费方
你在发布模块时不需要设置 GO_PRIVATE 或调整 GOPROXY。这些环境变量控制的是「谁在拉取你的模块」时的行为。真正关键的是：你的 go.mod 里每一行 require 所声明的模块路径，都必须能被任意第三方通过标准 Git 协议访问到——无论他们是否配置代理、是否跳过校验。路径错一位、权限少一级、tag 缺一个，下游就断。
立即学习“go语言免费学习笔记（深入）”；
最容易被忽略的点：你以为打了个 tag 就万事大吉，但没 push --tags 到远端；或者用了 SSH 地址却没在 ~/.gitconfig 配 insteadOf，导致别人用 HTTPS clone 时 404；又或者模块路径写了 git.example.com/internal/utils，但实际仓库 URL 是 https://git.example.com/group/utils —— 这些细微错位，都会让整个发布形同虚设。
