go get 默认走 HTTPS 而非 SSH，因 Go 底层调用 git clone 时将 go.mod 中模块路径（如 git.example.com/group/lib）直接解析为 HTTPS URL；须在 ~/.gitconfig 配置 insteadOf 规则才能启用 SSH。
go get 为什么默认走 HTTPS 而不是 SSH
因为 Go 工具链底层调用 git clone，而 git clone 默认解析模块路径为 HTTPS URL。比如你在 go.mod 中写 module git.example.com/group/lib，Go 就会尝试 https://git.example.com/group/lib，而不是 git@git.example.com:group/lib.git。
除非你提前在 ~/.gitconfig 里配置了重定向规则，否则 SSH 地址不会被自动识别。常见错误是：本地能 git clone git@git.example.com:group/lib.git 成功，但 go mod tidy 报 unknown revision —— 本质是协议不匹配。
- 必须确保
go.mod中的模块路径与 Git 仓库的 HTTPS 地址结构完全一致（包括域名、路径大小写） - 若要用 SSH，加这一行到
~/.gitconfig：[url "git@git.example.com:"]<br> insteadOf = https://git.example.com/
- 不要混用协议：同一仓库在不同项目中用了 HTTPS 和 SSH 两种路径，会导致
go.sum校验失败
如何让 go mod 支持自定义域名或 vanity import path
Go 不支持任意映射，但可通过 GOPROXY + vanity server 实现间接支持。例如你想用 mylib.company/internal 作为模块路径，实际代码托管在 git.company.com/internal/mylib，就得部署一个返回 301 重定向的 HTTP 服务：
访问 https://mylib.company/internal/@v/list → 返回 301 到 https://git.company.com/internal/mylib/@v/list；Go 会跟随重定向并继续拉取。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- vanity server 必须响应
/@v/list、/@v/vX.Y.Z.info、/@v/vX.Y.Z.mod、/@v/vX.Y.Z.zip四类路径 - 不能只靠
replace实现全局路径替换 —— 它只作用于当前模块，下游依赖仍会按原路径解析 -
GOINSECURE只跳过 TLS 校验，不解决路径映射问题；GOPRIVATE也只控制代理和校验开关，不改解析逻辑
replace 和 workspaces 在协议切换时的适用边界
replace 是静态路径替换，适用于开发阶段临时指向本地代码或私有分支；go work（Go 1.21+）则允许多模块协同开发，但两者都不改变模块路径的原始解析协议。
比如你用 replace github.com/foo/bar => ./bar，那 go build 会直接读本地文件，绕过网络拉取 —— 这时协议无关，但上线前必须删掉 replace 行，否则 CI 环境找不到 ./bar。
-
replace后的路径如果是远程地址（如replace example.com/lib => git.example.com/lib@main），Go 仍按 HTTPS 解析该地址，不触发 SSH - workspaces 中各模块的
go.mod路径必须彼此兼容，不能一个用git.example.com/lib，另一个用ssh://git@git.example.com/lib - CI/CD 环境禁用
replace和workspace，它们只适合本地开发流
私有仓库认证失败时最该检查的三件事
报错如 fatal: could not read Username for 'https://git.example.com': No such device or address 或 permission denied (publickey)，不是 Go 的问题，而是 Git 凭据没对上。
- 运行
git ls-remote -h https://git.example.com/group/lib.git（或对应 SSH 地址），确认能否手动拉取 —— 这步不通过，go mod必然失败 - HTTPS 方式下，检查
git config --global credential.helper是否启用，token 是否过期；避免把 token 写进go.mod或 URL 里 - SSH 方式下，确认
ssh -T git@git.example.com能成功，并且~/.ssh/config中 Host 别名与go.mod路径域名一致（如Host git.example.com）
协议选择不是配置问题，是路径、凭据、Git 配置三者对齐的结果。少一个环节，go mod download 就卡在“找不到仓库”这一步，而不是版本冲突或校验失败。
