必须配置goprivate跳过代理与校验，否则go默认将私有仓库当作公共模块处理，导致unknown revision或404；同时需确保go111module=on、module路径与仓库地址一致，并由系统git完成https token或ssh认证。
私有仓库拉不到依赖：先看 GOPRIVATE 配了没
Go 1.13+ 默认走模块模式，但对私有域名（如 gitlab.internal.company.com）仍会尝试走 GOPROXY 和校验 sum，结果就是 unknown revision 或 404 Not Found。根本原因不是网络不通，而是 Go 没被告知“这是私有模块，别代理、别校验”。
GOPRIVATE 是开关，不是地址列表——它告诉 Go 对匹配路径跳过 GOPROXY 和 GOSUMDB，转而用系统 git 直连。
- 必须用逗号分隔多个域名，不能有空格：
go env -w GOPRIVATE="gitlab.internal.company.com,github.com/myorg" - 支持通配符：
go env -w GOPRIVATE="*.internal.company.com"，但注意**不被识别，只认* - 值里不能含协议或路径，只写域名或子域名前缀；
https://或/team/project都会导致失效 - 验证是否生效：
go env GOPRIVATE应输出你设的值，且go mod download时不再报 401/404
HTTPS 私有仓库认证失败：git 和 Go 各管各的
配了 GOPRIVATE 还是卡在 x509: certificate signed by unknown authority 或 401 Unauthorized？那说明 Go 虽然绕过了代理，但底层拉代码仍靠系统 git 命令，而 git 的 HTTPS 认证和 TLS 校验是独立的。
Go 自身不复用系统 CA 证书库，git 也不自动读 Go 的配置。两者都要单独处理：
- 对
git的 HTTPS 认证：用git config --global http.https://gitlab.internal.company.com.extraheader "AUTHORIZATION: Bearer xxx"（Token 方式），或git config --global url."https://user:token@gitlab.internal.company.com".insteadOf "https://gitlab.internal.company.com" - 对
git的证书校验：运行git config --global http.sslCAInfo /path/to/internal-ca.crt，确保该文件是 PEM 格式、含完整信任链 - 对 Go 自身的 TLS 客户端（如
go get走 proxy 时）：Go 1.21+ 可设GOCERTIFICATEPATH=/path/to/ca-dir，目录下放*.crt或*.pem文件 - 不要设
GIT_SSL_NO_VERIFY=1—— 它只影响git，且绕过校验不安全；go get走 HTTPS proxy 时仍会失败
module path 和仓库地址不一致：checksum mismatch 的根源
go.mod 里的 module 指令不是命名空间，是唯一标识符。如果写成 module myproj，但实际托管在 https://gitlab.internal.company.com/team/project，后续 go get 就会拉错路径，导致 checksum mismatch 或找不到版本。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
必须严格一致：
- 初始化时就在空目录执行：
go mod init gitlab.internal.company.com/team/project，而不是在$GOPATH/src下随便 init - 如果已建项目，改
go.mod第一行后，需运行go mod edit -replace old/path=new/path并go mod tidy清理旧引用 - CI 构建时，确保
GO111MODULE=on，否则可能 fallback 到 GOPATH 模式，忽略go.mod中的 module 路径 - 私有仓库 tag 名必须符合语义化版本（如
v1.2.0），不能是release/v1.2或main—— Go 只认vX.Y.Z格式
HTTPS 服务端证书加载失败：路径、格式、权限三连坑
用 http.ListenAndServeTLS 或 gin.RunTLS 启动 HTTPS 服务时，报 tls: failed to find any PEM data 或 crypto/tls: private key does not match public key，基本是证书环节出错。
关键点不在 Go 代码逻辑，而在文件本身：
- 证书文件（
.crt或.pem）必须包含完整链：服务器证书 + 中间 CA（如有），顺序不能颠倒；浏览器提示NET::ERR_CERT_AUTHORITY_INVALID多因漏中间证书 - 私钥必须是未加密的 PEM 格式（开头
-----BEGIN RSA PRIVATE KEY-----），不能是 PKCS#8 或带密码的；用openssl rsa -in key-encrypted.pem -out key.pem解密 - 路径用绝对路径最稳，尤其 Docker 或 systemd 场景；Windows 上避免
转义，用正斜杠或双反斜杠：C:\certs\server.pem - 文件权限要放开：Linux 下
chmod 600 server.key是安全的，但若进程以非 root 用户运行，需确保该用户有读取权限，否则静默失败
真正麻烦的不是某一步不会做，而是错误信息模糊、多个组件（Go、git、系统 CA、证书链）各自校验又互不透传。先确认 GOPRIVATE，再查 git 认证，最后盯住证书文件内容——比反复改 Go 代码有效得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
