应配置 GOPROXY 和 GOSUMDB：执行 go env -w GOPROXY=https://goproxy.cn,direct && go env -w GOSUMDB=sum.golang.google.cn，再运行 go get github.com/gofiber/fiber/v2@v2.52.12。
go get 时如何指定国内镜像源拉取 fiber
直接用 go get github.com/gofiber/fiber/v2 在国内大概率失败或极慢，因为 GitHub 域名和 CDN 被干扰，且 Go 默认代理 proxy.golang.org 不可访问。必须显式配置 GOPROXY 才能稳定安装。
推荐使用 https://goproxy.cn（中国信通院维护）或 https://goproxy.io（已归档但多数仍可用），二者都完整缓存了 fiber 的所有 tag 和 module。
- 临时生效（仅当前命令）：
GO111MODULE=on GOPROXY=https://goproxy.cn,direct go get github.com/gofiber/fiber/v2@v2.52.12 - 全局生效（推荐）：
go env -w GOPROXY=https://goproxy.cn,direct，之后所有go get、go mod download都自动走镜像 - 如果项目已存在
go.mod，且之前用过官方 proxy 导致缓存损坏，先删掉go.sum并运行go mod tidy -v强制重拉
go mod download 失败提示 “checksum mismatch” 怎么办
这不是 fiber 本身的问题，而是 GOPROXY 切换后，go.sum 里旧的校验和与新源返回的归档包不一致。Go 拒绝加载以保证完整性，但此时它并非被篡改，只是镜像源对同一 commit 打包方式略有差异（比如压缩参数、时间戳）。
- 不要手动删
go.sum行，那会破坏依赖锁定 - 正确做法是：运行
go mod download -v，让 Go 自动重新计算并更新go.sum中 fiber 及其间接依赖的 checksum - 若仍卡住，加
-x参数看具体哪个 module 失败，再单独go get -u它
为什么不能只配 GOPROXY 而忽略 GOSUMDB
GOSUMDB 默认是 sum.golang.org，它负责验证 module checksum 是否被篡改。一旦你用了国内镜像源，而 GOSUMDB 还指向境外服务，就会出现“校验服务器不可达 → 校验跳过 → 安全警告 → 拒绝执行”的连锁反应。
- 必须同步关闭校验或换为可信替代：
go env -w GOSUMDB=off（开发阶段可接受） - 更稳妥的做法：
go env -w GOSUMDB=sum.golang.google.cn（Google 中国镜像，支持 fiber 所有版本） - 注意：生产构建 CI/CD 流程中，
GOSUMDB=off是高风险操作，应坚持用sum.golang.google.cn
vendor 目录下 fiber 的依赖为何还是从 GitHub 下载
如果你用 go mod vendor 后执行 go build -mod=vendor，但构建时仍尝试连 GitHub，说明 vendor 并未真正隔离网络依赖——常见原因是：go.mod 里 fiber 的 require 行写的是 github.com/gofiber/fiber/v2 v2.52.12，而 Go 在 vendor 模式下仍会去校验该路径的原始 repo 是否存在（即使不用它）。
- 解决方案一：构建前确保
GO111MODULE=on GOPROXY=https://goproxy.cn,direct go mod vendor，这样 vendor 里的 zip 包元信息已绑定镜像源 - 解决方案二：在 CI 环境中加
go env -w GOPROXY=https://goproxy.cn,direct GOSUMDB=sum.golang.google.cn，再跑go mod vendor - 关键点：vendor 不是“断网打包”，而是“离线构建”，前提是 vendor 内容本身得由可信 proxy 生成
fiber 的 module path 和版本发布完全遵循 Go Module 规范，没有私有 registry 或定制分发逻辑，所以只要 proxy 和 sumdb 配置对齐，就不会有奇怪的 404 或 hash error。最容易被忽略的是 GOSUMDB 和 GOPROXY 的组合策略——它们必须协同生效，缺一不可。
