GOPROXY 必须指向可控的中间代理服务而非直连 proxy.golang.org，正确配置应为多级 fallback（如 https://internal-proxy.company.com,direct），并配合 GONOSUMDB 等严格限制直连；私有模块需统一使用可解析域名、打语义化 tag，并由 proxy 规则引擎路由，replace/exclude 仅限本地开发，不可用于全局依赖治理。
GOPROXY 必须指向可配置、可审计的中间代理服务
直接设 GOPROXY=https://proxy.golang.org 会绕过公司内控，所有模块请求都直连公网，既无法审计依赖来源，也无法拦截高危包或替换私有模块。正确做法是部署一个可控的代理服务（如 Athens、JFrog Artifactory 或自建 Go proxy），然后把 GOPROXY 指向它。
常见错误是只配单个地址：一旦该代理宕机，go build 直接失败。应使用逗号分隔多级 fallback：GOPROXY=https://internal-proxy.company.com,direct，其中 direct 是兜底项，仅在代理不可用时才尝试直连——但需配合 GONOSUMDB 和 GOINSECURE 严格限制直连范围。
-
GOPROXY值中不能含空格，否则go命令解析失败 - 若代理服务启用了 Basic Auth，URL 中需写成
https://user:pass@internal-proxy.company.com，但密码明文存在风险，建议改用 token header 或反向代理前置鉴权 - 私有模块域名（如
git.company.com/internal/lib）必须加入GONOSUMDB，否则 go 会拒绝校验 checksum，导致go get报错checksum mismatch
go.mod 中 replace 和 exclude 不是流量控制手段，而是临时补丁
replace 和 exclude 写在 go.mod 里，只影响当前 module 的构建行为，对其他项目无效，也无法被 go proxy 服务识别或执行。它们本质是本地开发期的“覆盖指令”，不是依赖流向的策略层控制。
真正要规范全公司流向，得靠 proxy 服务本身的规则引擎。例如 Athens 支持 config.yaml 中定义：
立即学习“go语言免费学习笔记（深入）”；
repositories: - name: "company-internal" url: "https://git.company.com/internal" vcs: "git" - name: "public-go-modules" url: "https://proxy.golang.org" allow: ["github.com/*", "golang.org/*"]
这样，当 go get github.com/sirupsen/logrus 时走 public 规则；而 go get git.company.com/internal/auth 强制走 internal 规则，且不经过公网。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
replace在 CI 环境中可能失效——某些 CI runner 会清理 vendor 或忽略 replace，导致行为不一致 - 多个
replace嵌套（如 A replace B，B replace C）极易引发循环依赖，go list -m all会报错invalid version - 上线前务必运行
go mod verify，确认所有模块 checksum 与 proxy 返回一致，防止中间人篡改
私有模块路径必须统一注册到 GOPROXY，而非靠 GOPATH 或 local file path
有人试图用 replace example.com/pkg => ./pkg 或 replace example.com/pkg => /abs/path/to/pkg 绕过 proxy，这会导致两个严重问题：一是团队协作时路径不一致直接 break build；二是 go mod download 无法拉取该模块，vendor 生成失败。
正确路径规范是：所有私有模块必须使用唯一、可解析的域名（如 go.company.com/auth），并在内部 DNS 或 /etc/hosts 中解析到公司 proxy 服务。proxy 收到对该域名的请求后，按预设规则路由到对应 Git 仓库或本地 fs。
- Git 仓库 URL 必须与模块导入路径完全一致，比如
go.company.com/auth对应 Git 地址https://git.company.com/go/auth，否则go proxy无法定位版本标签 - 模块根目录下必须有
go.mod文件，且第一行module go.company.com/auth与导入路径严格匹配，大小写敏感 - 避免用
master或main分支作为默认版本——go get go.company.com/auth会 fallback 到 latest tag，没 tag 就报错；应确保每次发布都打语义化 tag（如v1.2.0）
流量审计日志必须包含 module path + version + client IP + timestamp
单纯配置 proxy 不等于完成合规。真正关键的是能回溯“谁、在什么时间、下载了哪个模块的哪个版本”。Athens 默认只记录 access log，字段有限；Artifactory 可开启详细审计日志，但需手动勾选 “Include request parameters”。
若自研 proxy，务必在 handler 中提取并落盘以下字段：
-
req.URL.Path—— 解析出 module path（如/go.company.com/auth/@v/v1.2.0.info） -
req.Header.Get("User-Agent")—— 区分是go cmd还是 IDE 插件发起的请求 -
getClientIP(req)—— 避免只记 proxy 自身 IP，要用X-Forwarded-For或 real IP header - 响应状态码和耗时 —— 用于识别高频失败模块，可能是权限或网络问题
这些日志要接入公司 SIEM 系统，设置告警规则：比如 1 小时内同一 IP 请求 >50 个不同私有模块，触发安全复核。
最容易被忽略的一点：proxy 服务自身的依赖（如 Athens 用的 Redis、PostgreSQL）也必须纳入审计范围——如果缓存层被攻破，恶意模块可能长期驻留而不被发现。
