靠 go mod download 的缓存机制 + 代理分流 + 并发限制，比改下载参数更有效；Go 本身不提供“压缩传输”或“跳过源码”的带宽参数，因其模块下载底层为 HTTP(S) GET 请求，不支持压缩协商，且模块包已是 zip 格式，天然压缩。
直接结论：靠 go mod download 的缓存机制 + 代理分流 + 并发限制，比改下载参数更有效；Go 本身不提供“压缩传输”或“跳过源码”的带宽参数。
为什么不能用 -compress 或类似参数缩减带宽
Go 的模块下载（go get / go mod download）底层走的是 HTTP(S) GET 请求，不支持服务端压缩协商（如 Accept-Encoding: gzip），也不提供客户端解压开关。模块包本身就是 zip 格式（.zip 后缀的 module zip），已天然压缩——你没法再“二次压缩”。试图加 -v 或 -x 只影响日志输出，不改变传输体积。
真正能压带宽的三个实操点
带宽占用高，本质是重复拉取、无效重试、全量下载。解决方向不是“参数”，而是“避免重复传、减少重传、按需拉”：
-
go mod download默认会把所有依赖（含间接依赖）完整拉到本地pkg/mod缓存目录——只要缓存存在，后续构建/测试/运行完全不走网络，这是最省带宽的操作，但首次仍需全量 - 设置
GOPROXY为国内镜像（如https://goproxy.cn）可显著降低 TCP 建连和 TLS 握手开销，尤其对小模块（几十 KB）效果明显；多个模块复用同一代理连接，比直连 GitHub 每个 repo 单独建连省得多 - 用
go mod download -json配合脚本预判依赖树，再结合go mod download -modfile=go.mod.xxx分批下载核心模块（比如只下runtime相关链），跳过测试/示例/文档等非运行时必需内容——但这需要你知道哪些模块真被 import，且风险是构建失败
容易被忽略的并发与重试放大带宽问题
默认 go mod download 并发数由 Go 运行时自动控制（通常 4–8），看似快，但在弱网或代理不稳定时，频繁超时重试会反复拉同一 zip 文件片段，实际带宽翻倍。解决方案很朴素：
立即学习“go语言免费学习笔记（深入）”；
- 临时降并发：设环境变量
GODEBUG=gomodfetch=1（Go 1.21+），强制串行下载，减少连接争抢和重试概率 - 关掉冗余重试：在公司内网或可信代理环境下，把
GOPROXY末尾的direct去掉，避免 fallback 到慢速直连触发二次下载 - 禁用 checksum 验证（仅限离线可信环境）：加
-insecure参数跳过sum.golang.org校验请求——少一次 HTTPS 请求，也少一次可能的重定向
真正起效的不是某个 magic 参数，而是理解 Go 模块下载的三层行为：代理路由 → HTTP 获取 → 本地解压缓存。带宽瓶颈往往卡在第一层（DNS/TLS/连接复用）和第二层（重试放大），而不是第三层（zip 大小）。调参前，先看 go env -w GOPROXY=https://goproxy.cn 是否生效，再确认 pkg/mod/cache/download/ 是否被复用——这才是压带宽的起点。
