git credential helper 配置缺失会导致 go mod download 卡在 git clone 环节，因 Git 等待无提示的密码输入而挂起；应配置 git config --global credential.helper store（Linux/macOS）或 manager-core（Windows），并首次手动 git clone 触发凭据存储。
git credential helper 配置缺失导致 go mod 下载卡住
Go 调用 git clone 拉取私有模块时，若系统未配置凭据助手，会阻塞在交互式密码输入环节——但终端无提示、进程不报错、go mod download 无限挂起，看起来像“死锁”。这不是 Go 的并发死锁，而是 Git 等待 stdin 输入卡住。
常见现象：
-
go mod tidy卡住数分钟，CPU 占用极低，ps aux | grep git显示git-credential子进程处于S（sleep）状态 - 手动执行
git clone https://git.example.com/group/lib.git同样卡住，证实是 Git 层问题
实操建议：
- Linux/macOS：运行
git config --global credential.helper store，首次拉取会弹出密码框并存入~/.git-credentials - macOS 更推荐
git config --global credential.helper osxkeychain，复用系统钥匙串 - Windows：启用
git config --global credential.helper manager-core - 避免用
git config --global user.password硬编码密码——Git 已弃用该配置，且不生效
HTTPS URL 中嵌入 token 导致 404 或 403
部分私有 Git 平台（如 Gitea、Bitbucket Server）不支持 https://token:x-oauth-basic@host/repo 格式，或要求 token 具备特定 scope（如 read_repository），结果 go get 返回 404 Not Found 或静默失败。
立即学习“go语言免费学习笔记（深入）”；
关键点：
- GitHub/GitLab 支持该格式，但 token 必须含
read_package_registry（GitLab）或repo（GitHub）权限 - Gitea 默认禁用 basic auth over token，需在
app.ini中设置DISABLE_HTTP_TOKEN_AUTH = false - URL 中的
x-oauth-basic是占位符，不是固定字符串；某些平台要求填token或留空
验证方式：
- 手动 curl 测试：
curl -I -u "token:" https://git.example.com/group/lib/info/refs?service=git-upload-pack - 若返回
401 Unauthorized，说明认证机制生效但凭证无效；若返回404，说明路径或权限不对
SSH agent 未加载私钥导致 Host key verification failed
用 SSH 地址（如 git@git.example.com:group/lib.git）时，go mod 会调用 ssh -o StrictHostKeyChecking=no git@git.example.com，但若 ssh-agent 未运行或未添加私钥，就会报 Host key verification failed 或 Permission denied (publickey)。
排查步骤：
- 确认私钥已加载：
ssh-add -l应列出对应 key；若为空，执行ssh-add ~/.ssh/id_rsa - 检查
~/.ssh/config是否覆盖了git.example.com的 User 或 IdentityFile，导致连接错用 key - 临时绕过 host key 检查仅用于调试：
ssh -o StrictHostKeyChecking=no git@git.example.com—— 成功则说明是 host key 缓存问题，需ssh-keyscan git.example.com >> ~/.ssh/known_hosts - CI 环境必须显式启动 agent：
eval $(ssh-agent -s)+ssh-add /path/to/key，不能依赖登录 shell 的 agent
GO_PROXY 和 GOPRIVATE 配置冲突引发静默跳过
当 GOPRIVATE 未包含私有域名，而 GO_PROXY 又设为非空（如 https://proxy.golang.org），Go 会尝试通过代理拉取私有模块——代理返回 404 后，工具链不会 fallback 到直连，而是直接报错 no required module provides package，看似依赖丢失，实为代理拦截。
必须同时满足三项：
-
GOPRIVATE=git.example.com（逗号分隔多个域名，支持通配符*） -
GO_PROXY=direct或https://proxy.golang.org,direct（direct表示对GOPRIVATE域名跳过代理） -
GOINSECURE仅在 HTTP 协议时需要，HTTPS 下无需设置
验证配置是否生效：
- 运行
go env GOPRIVATE GO_PROXY，确认输出符合预期 - 执行
go list -m all 2>&1 | grep git.example.com，若显示git.example.com/group/lib v0.1.0且无错误，说明已直连成功
最易被忽略的是：CI 环境里 GOPRIVATE 常被硬编码在构建脚本中，但开发机上靠 shell profile 设置，两者不一致会导致本地能拉、CI 失败。
