应选v2（生产推荐）或v3（仅Go≥1.24且接受测试阶段风险）；二者为完全独立模块，需严格匹配Go版本、导入路径与API调用，混用将导致编译失败。
Fiber 框架本身没有“多版本安装”或“运行时切换框架版本”的机制——你只能在项目中显式选择 v2 或 v3 之一，并确保 Go 版本、导入路径、API 调用完全对齐；混用或试图共存会导致编译失败或行为不可控。
怎么选 v2 还是 v3？看 Go 版本和稳定性需求
-
go version 1.21+→ 可用github.com/gofiber/fiber/v2（生产推荐） -
go version 1.24+→ 才能用github.com/gofiber/fiber/v3（v3 截至 2026 年 10 月仍为测试阶段） go version → 无法安装任一现代版，必须先升级 Go
常见错误：
- 用
go get github.com/gofiber/fiber（不带/v2）→ 拉取过时的 v1，已废弃 - 在
go 1.23下执行go get github.com/gofiber/fiber/v3→ 编译报错：undefined: fiber.NewWithCustomCtx等新 API 不可用 -
go.mod中同时存在v2和v3的 import →go build直接失败：“duplicate import”
如何安全地在项目间切换 Fiber 版本
不是“全局切换”，而是每个项目独立声明依赖：
- 初始化新项目时，明确指定版本：
go mod init myapi go get github.com/gofiber/fiber/v2
- 升级已有项目到 v3（仅当 Go ≥ 1.24）：
go get github.com/gofiber/fiber/v3 # 然后手动修改所有 import 行： # ❌ "github.com/gofiber/fiber/v2" # ✅ "github.com/gofiber/fiber/v3"
- 切换后必须检查三处：
-
fiber.New()参数结构是否变化（v3 移除了Config.DisableStartupMessage等字段） - 中间件签名（v3 中
fiber.Handler返回error，但部分内置中间件入参有调整） -
ctx.Query()、ctx.Params()等方法行为是否一致（v3 对空参数解析更严格）
-
为什么不能像 Node.js 那样用 nvm 管理 Fiber 版本
- Fiber 是 Go 的库依赖，不是可执行 CLI 工具；它不提供全局二进制或 runtime 环境
- Go 的模块系统（
go.mod）强制每个项目锁定具体版本，不存在“当前 Fiber 版本”概念 - 你看到的
v2/v3是 Go Module 的语义化版本路径，由 import 语句决定，与操作系统无关
所以：
- 不需要
nvm-style 工具 - 不要尝试
go installFiber - 不要删
$GOPATH/pkg来“清理旧版”——Go Modules 会自动隔离不同项目的依赖版本
关键点就一个：v2 和 v3 是两个完全独立的模块，就像 github.com/foo/lib 和 github.com/foo/lib-pro。你不可能在同一个 go build 中同时用它们——这不是限制，而是 Go 模块设计的必然结果。真正要管理的，是每个项目的 go.mod 和对应的 Go 版本。
