根本原因是GOPRIVATE未正确配置或Git凭证未生效；前者导致Go跳过认证直连失败，后者使SSH/HTTPS鉴权中断，其余报错均为这两类问题的衍生表现。
Go 拉取私有 Git 仓库模块时鉴权失效，根本原因只有两个：要么 GOPRIVATE 没配对，要么凭证没走通。其他表现（如 go get 卡住、报 401 Unauthorized、提示 unknown revision）都是这两个问题的衍生物。
GOPRIVATE 配置不生效或范围错误
Go 默认把所有模块都当成公共包处理，会强制走 proxy.golang.org 和 sum.golang.org，一旦遇到私有域名就直接拒绝——不是密码错，是压根没发请求过去。
-
GOPRIVATE必须精确匹配你的仓库域名，支持通配符但不支持子域名自动继承。比如你用gitea.internal.company.com，就不能只设company.com；得写成gitea.internal.company.com或gitea.internal.company.com/* - 如果用了路径前缀（如
gitea.internal.company.com/myteam/），GOPRIVATE只需覆盖域名层级，不用带路径；但GONOPROXY和GONOSUMDB可以省略，因为GOPRIVATE已隐含这两项 - 检查是否被 shell 环境覆盖：运行
go env GOPRIVATE看输出，别只信go env -w的返回——它可能写进了错误的配置文件（比如写到了~/.bash_profile，但你用的是 zsh）
SSH 方式拉取失败的典型断点
SSH 是最稳定的免密方案，但断在中间环节时，错误往往不报 SSH 相关关键词，而是笼统提示 unknown revision 或 ref not found。
- Git 的
insteadOf规则必须严格匹配 URL 结构：git config --global url."git@gitea.internal.company.com:".insteadOf "https://gitea.internal.company.com/"—— 注意末尾的/和:不能少，也不能多 - Go 不调用
ssh-agent，只认~/.ssh/id_rsa或~/.ssh/id_ed25519这类默认命名的私钥。如果你用了自定义名字（比如id_gitea），得在~/.ssh/config里显式声明：Host gitea.internal.company.com\n IdentityFile ~/.ssh/id_gitea - 测试是否真连得上：运行
ssh -T git@gitea.internal.company.com。如果提示Permission denied (publickey)，说明 SSH 层就没通，Go 层根本不会启动
.netrc 凭证方式被 Go 忽略的常见原因
Go 从 1.19 开始才正式支持读取 .netrc，且只在 HTTP(S) 场景下生效；它不走系统 credential helper，也不读 git config credential.helper 的输出。
立即学习“go语言免费学习笔记（深入）”；
-
.netrc文件权限必须是600（chmod 600 ~/.netrc），否则 Go 直接跳过读取 - machine 名必须和
GOPRIVATE域名完全一致，包括端口（如gitea.internal.company.com:3000），且不能带协议头 - token 必须是 Gitea 的 Personal Access Token，不是登录密码；权限至少勾选
read:repository，如果是 push 还要加write:repository - 如果仓库 URL 是
https://gitea.internal.company.com/myorg/mymodule，而.netrc里写的是machine gitea.internal.company.com/myorg，那就不匹配——machine行只接受域名+可选端口，不接受路径
最容易被忽略的一点：Gitea 的 API 路径和 Git 路径可能不同。比如 Git 克隆地址是 https://gitea.internal.company.com/myorg/mymodule.git，但 Go 模块路径声明是 module gitea.internal.company.com/myorg/mymodule——这个模块路径必须和实际 Git 仓库的 URL 路径结构一致，否则 Go 会尝试访问一个不存在的 /info/refs?service=git-upload-pack 端点，导致 404 后退回到 proxy，最终报错。
