Fiber身份认证需明确选择Session或JWT方案：JWT需手动解析token并区分错误类型，Cookie方式须用c.Cookies.Get且配置Secure和SameSite；Session必须使用Redis等外部存储，登录后调sess.Set和sess.Save，登出时调sess.Destroy；中间件应返回具体错误状态码，避免panic，并为可选认证调c.Next()。
直接用 Fiber 实现身份认证，核心不是“加个中间件就完事”，而是得明确你用的是 Session 还是 JWT，以及用户凭证从哪来、怎么校验、状态怎么维持。Fiber 本身不内置认证逻辑，所有方案都依赖你组合 fiber.Cookie、jwt.Parse、数据库查询和中间件控制流。
JWT 认证：token 放 Header 还是 Cookie？
大多数前后端分离项目用 Bearer Token，即前端在请求头带 Authorization: Bearer <token>；但若要支持 CSRF 防护或跨域凭据传递，就得改用 HttpOnly Cookie 存 token —— 此时后端必须用 c.Cookies.Get("auth_token") 读取，不能依赖 c.Get("Authorization")。
- 用 Header 方式时，解析 token 必须手动调
jwt.Parse，且需检查err == jwt.ErrTokenExpired和err == jwt.ErrTokenInvalid - 用 Cookie 方式时，记得在签发 token 后调
c.Cookie(&fiber.Cookie{...})，并设Secure: true（HTTPS 环境）和SameSite: fiber.CookieSameSiteStrictMode（防 CSRF） - Fiber 默认不自动解析 Authorization 头里的 JWT，
c.Locals里不会自动塞user，得你自己解析完存进去
Session 认证：别直接用内存存储
Fiber 的 fiber.New() 默认 session 存内存，重启服务就丢全部登录态，开发可以，上线必须换存储后端。Session ID 通常由 fiber.Cookie 携带，但校验逻辑全靠你写：查 Redis、比对 user_id、检查过期时间。
- 用
github.com/gofiber/fiber/v2/middleware/session时，session.New()的Store参数必须传 Redis 或 Badger 实例，不能留空 - 登录成功后，要显式调
sess.Set("user_id", 123)和sess.Save()，否则数据不落盘 - 登出时仅清除 cookie 不够，还得调
sess.Destroy()删除服务端 session 数据，否则 token 仍可被重放
中间件里如何拒绝未授权访问？
认证中间件不该只做“有没有 token”，而要区分“token 无效”“token 过期”“用户不存在”三种情况，并返回不同 HTTP 状态码和响应体。Fiber 的 c.Status().JSON() 要在中间件里尽早调用，且必须紧跟 return，否则后续路由仍会执行。
- 错误处理建议统一返回：
c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid or expired token"}) - 不要在中间件里用
panic或log.Fatal，Fiber 的错误恢复机制会吞掉 panic，导致静默失败 - 如果路由需要“可选认证”（比如首页允许游客访问），中间件里检测到无 token 应直接
c.Next()，而不是返回错误
最常被忽略的点是 token 刷新逻辑 —— JWT 过期后，前端拿 refresh_token 换新 access_token，这个流程要单独开一个 POST /refresh 接口，且 refresh_token 必须存服务端（Redis + 随机字符串 + 绑定 user_id + 过期时间），不能只靠 JWT 自签名。Fiber 不提供开箱即用的刷新机制，每一步都得你手写验证和签发。
