Fiber 框架本身不涉及重复安装，所谓“重复安装慢”实为 Go 模块下载、校验、构建的开销；加速应从 Go 工具链入手，利用 Go proxy 和模块缓存（$GOPATH/pkg/mod）可解决 95% 问题。
go get 安装的是 Go 模块，不是运行时可缓存的资源；所谓“重复安装慢”，本质是 Go 模块下载、校验、构建环节的重复开销，和 Fiber 无关。加速的关键在 Go 工具链层，不是 Fiber 配置层。
Go proxy 和 GOPATH/pkg 缓存能解决 95% 的“重复安装”问题
Go 自带模块缓存机制，只要没清空 $GOPATH/pkg/mod 或禁用 proxy，第二次 go get github.com/gofiber/fiber/v2 几乎不走网络：
- 首次执行会从 proxy（如
https://proxy.golang.org）下载 zip 并解压到本地模块缓存目录 - 后续相同版本请求直接复用本地文件，
go get耗时通常 - 若你手动删了
pkg/mod、或设了GOPROXY=direct，才真正触发重下载
CI/CD 中避免反复 go get 安装 Fiber
在 GitHub Actions、GitLab CI 等场景下，“重复安装”常源于每次构建都重跑 go get。正确做法是：
- 用
go mod download预热模块缓存（它只下载不安装，且支持并发） - 确保
go.mod和go.sum已提交，CI 中直接go build即可，无需go get - 在 Docker 构建中，把
go mod download放在COPY go.mod go.sum .之后、COPY . .之前，利用 layer 缓存
别在 main.go 里写 go get 或自动安装逻辑
有人试图用 exec.Command("go", "get", "...") 在启动时“动态安装 Fiber”，这是严重错误：
- Go 模块系统不允许运行时修改依赖；
go get修改的是当前 module 的go.mod，不是内存中的框架实例 - 这会导致竞态：多个请求同时触发 install、写冲突
go.mod、破坏构建一致性 - Fiber 是编译期依赖，不是插件式运行时加载项；所谓“安装”只是获取源码并参与构建
go.mod 锁定、CI 分层构建——这些才是实际生效的点。Fiber 本身没有安装态，也不提供缓存安装接口。 
