go get github.com/gofiber/fiber/v2 卡住或失败的根源是模块拉取问题，而非传输中断；主因包括 goproxy 配置不当、网络限制、私有依赖阻塞、git:// 协议被禁、版本冲突等，可通过指定版本、设置可信代理、分步下载、vendor 离线方案等解决。
Fiber 框架本身不涉及“安装中断”或“断点续传”——go get 下载的是 Go 模块源码，不是大文件传输，不存在传统意义上的断点续传机制。所谓“安装总是中断”，本质是 Go 模块拉取失败，根源在 GOPROXY、网络策略或模块依赖解析卡死，不是传输层问题。
为什么 go get github.com/gofiber/fiber/v2 会卡住或失败
go get github.com/gofiber/fiber/v2 会卡住或失败Go 的模块下载走的是 HTTP + Git 协议组合，但实际行为取决于 GOPROXY 配置和底层 git clone 行为：
- 默认 GOPROXY=direct 时，
go get会尝试直连 GitHub（受限于 DNS、GFW、IPv6 fallback 等），常卡在resolving imports或verifying github.com/... - 即使配置了代理，若模块依赖中含私有仓库或 submodule，
go mod download可能静默 hang 在某个间接依赖上，不报错也不退出 - 某些企业内网禁用 git:// 协议，而部分旧模块的 go.mod 仍写死
git://地址，导致 clone 失败 -
go get -u强制升级所有依赖，容易触发版本冲突或不兼容的 indirect 依赖，引发 resolve 循环或超时
绕过失败：用 go mod download + 缓存重试
go mod download + 缓存重试比反复 go get 更可靠的做法是分步控制下载过程，利用 Go 自带的模块缓存机制实现“类续传”：
- 先运行
go mod init myapp初始化模块，再go mod edit -require=github.com/gofiber/fiber/v2@v2.52.0（指定已知稳定版） - 执行
go mod download -x（-x 打印每一步命令），观察卡在哪一跳依赖；若卡住，Ctrl+C 中断后再次运行，Go 会复用已下载的模块，只拉取剩余部分 - 把 GOPROXY 设为可信镜像，例如：
export GOPROXY=https://goproxy.cn,direct（国内）或export GOPROXY=https://proxy.golang.org,direct（海外） - 避免
-u：改用go get github.com/gofiber/fiber/v2@v2.52.0锁定版本，不递归升级间接依赖
网络不稳定时的兜底方案：离线预下载 + vendor
在可联网环境提前下载好完整依赖树，再拷到目标机器，彻底规避实时网络问题：
- 在干净目录执行：
go mod vendor，生成vendor/文件夹（包含所有依赖源码） - 把整个项目（含 vendor）打包带走，在目标机器运行
go build -mod=vendor - 注意：
go run默认不读 vendor，必须显式加-mod=vendor参数，否则仍会尝试联网 - vendor 方案适合 CI/CD 离线构建、信创环境或强审计场景，但会增大项目体积
真正卡住的地方往往不是 Fiber 本身，而是它依赖的 github.com/valyala/fasthttp 或其子依赖（比如 github.com/goccy/go-json）。盯着日志里最后出现的模块名，针对性换镜像或降级版本，比盲目重试更有效。
