单体架构迁移时不能直接go get -u重装Fiber，因v2与v3 import路径混用会导致编译失败或panic；v3要求Go 1.24+，而多数单体项目仍用Go 1.21–1.23，且go get -u不会自动修复fiber.Default()调用或StrictRouting配置差异。
单体架构迁移时不需要“重新安装”Fiber框架——它不是需要重装的系统组件，而是项目依赖项；真正要做的，是清理旧引用、校准版本、重建初始化逻辑。
为什么不能直接 go get -u 重装
在单体项目中混用 Fiber v2 和 v3 的 import 路径（如 github.com/gofiber/fiber/v2 与 github.com/gofiber/fiber/v3）会导致编译失败或运行时 panic。v3 要求 Go 1.24+，而多数单体项目仍基于 Go 1.21–1.23；盲目执行 go get -u 可能拉取不兼容版本，且不会自动修复已存在的 fiber.Default() 调用或 StrictRouting 配置差异。
- 检查当前依赖：运行
go list -m all | grep fiber确认实际引入的版本 - 若输出含
v3但 Go 版本 go get github.com/gofiber/fiber/v2@latest - 删掉
go.sum中所有v3相关行，再go mod tidy重算依赖树
fiber.Default() 必须替换成 fiber.New()
单体项目常沿用快速启动写法，比如直接 app := fiber.Default()，但这在迁移后会暴露严重问题：默认中间件（Logger、Recover）在高并发下拖垮性能，且 Logger 会把敏感头（如 Authorization）明文写入日志。
- 上线前必须替换为
app := fiber.New() - 按需添加中间件：开发环境加
logger.New()，生产环境只加recover.New(recover.Config{EnableStackTrace: false}) - 禁用启动横幅：
fiber.Config{DisableStartupMessage: true}，避免干扰日志采集
StrictRouting 不一致会导致路由 404
老单体项目可能习惯性注册 app.Get("/users", handler)，但新 Fiber 默认开启 StrictRouting: true，此时访问 /users/（带尾部斜杠）会直接 404，而非自动重定向。
- 不要全局设
StrictRouting: false——这会让/users和/users/:id冲突，c.Params("id")拿不到值 - 推荐方案：加一个重定向中间件，统一将
/xxx/→/xxx（301） - 临时验证可用
app.Get("/users/", handler)显式注册，但仅限调试，不可上线
最容易被忽略的是 fiber.Ctx 复用机制——它不是每次请求新建对象，而是从池中复用。迁移时若在 handler 中调用 c.Locals("key", value) 存上下文，又没清空，后续请求可能读到上一个请求残留的数据。
