fiber 没有全局数据库连接注入，依赖需显式挂载或闭包捕获；正确做法是启动时用 app.use 绑定 db 到 ctx.locals，或扩展 app 结构体持有 db 实例，并确保应用退出时统一调用 db.close()。
直接说结论：Fiber 没有“全局数据库连接注入”这回事，所谓“注入”本质是手动传递或封装成 fiber.Ctx 的键值对，中间件里不能自动 DI。
为什么 Fiber 中间件无法像 Spring Boot 那样自动注入数据库连接
Fiber 是轻量级 HTTP 框架，基于 Go 原生 net/http，不带 IoC 容器、不支持构造函数注入或字段反射注入。它的中间件只接收一个 *fiber.Ctx 参数，所有依赖必须显式挂载或从外部闭包捕获。
- 没有内置的依赖注入机制，
database/sql或gorm.DB实例不会自动出现在ctx里 - 中间件执行时，
ctx是每次请求新建的，不能靠“单例注入”把 DB 实例塞进结构体字段 - 若强行在中间件里初始化 DB（比如调用
sql.Open），会导致连接泄漏、重复建连、配置不可控
正确做法：把 DB 实例挂到 fiber.App 或通过 ctx.Locals 透传
推荐两种安全、可测试、符合 Fiber 习惯的方式：
- 将
*sql.DB或*gorm.DB作为字段挂到自定义 App 结构体上，中间件通过ctx.App()取（需自己扩展fiber.App） - 更常用的是在启动时用
app.Use(func(c *fiber.Ctx) error { c.Locals("db", dbInstance); return c.Next() })，后续中间件或 handler 用c.Locals("db")取——但注意这只是临时绑定，不是生命周期管理 - 不要在中间件里做
db.Ping()或事务开启，这些应放在业务 handler 或专用 DB 中间件（如txMiddleware）中按需处理
ctx.Locals 和 ctx.Context().Value 的区别与风险
两者都可用于传递 DB 实例，但行为不同：
-
ctx.Locals(key)是 Fiber 自带的 request-scoped 存储，key 是interface{}，类型安全靠断言，适合短生命周期传递（如当前请求的 DB 实例） -
ctx.Context().Value(key)是 Go 标准库 context 机制，穿透性更强（跨 goroutine 仍有效），但容易被意外覆盖或遗忘清理，且和 Fiber 生命周期不完全对齐 - 常见错误：用字符串 key（如
"db"）导致拼写错，建议定义常量const DBKey = "db"；更严重的是把未初始化的nilDB 赋给Locals，后续断言 panic
真正麻烦的不是“怎么挂”，而是“谁负责 Close”。DB 连接池应在应用退出时统一 db.Close()，而不是交给某个中间件或请求生命周期。这点容易被忽略，尤其在热重载或容器化部署时，残留连接会堆积。
