fiber 不内置 session 支持，cookie 需手动设置 httponly、secure、samesite 等安全属性；session 必须集成第三方中间件（如 fiber/session + redis），内存存储仅限开发；典型陷阱包括 secure cookie 在 http 下失效、前端未发送 credentials、跨域配置缺失及 session 过期未自动刷新。
Fiber 框架本身不内置 Session 支持，Cookie 设置简单但必须手动处理安全属性。它默认只提供轻量级的 Cookie 操作能力，Session 需要额外集成第三方中间件（如 fiber/storage + fiber/session），且默认内存存储不具备生产可用性。
怎么用 Fiber 设置 Cookie
Fiber 通过 c.Cookie() 和 c.SetCookie() 提供原生支持，但要注意：它不自动处理 HttpOnly、Secure、SameSite 等关键安全字段，漏设极易导致 XSS 或 CSRF 风险。
-
c.SetCookie()是推荐方式，能一次性设置所有属性；c.Cookie()只读取，不能设值 - 必须显式调用
cookie.HTTPOnly(true)和cookie.Secure(true)（HTTPS 环境下），否则前端 JS 可读写 -
SameSite建议设为Lax或Strict，避免跨站请求携带，Fiber v2.50+ 才支持cookie.SameSite(fiber.SameSiteLaxMode) - 过期时间用
cookie.MaxAge(3600)（秒），不要依赖Expires字段，后者易因客户端时间偏差失效
func setAuthCookie(c *fiber.Ctx) error {
cookie := fiber.Cookie{
Name: "auth_token",
Value: "abc123",
Path: "/",
MaxAge: 3600,
HTTPOnly: true,
Secure: true, // 生产环境必须为 true
SameSite: fiber.SameSiteLaxMode,
}
c.SetCookie(&cookie)
return c.SendString("cookie set")
}
为什么 Fiber 默认没有 Session
Fiber 的设计哲学是“按需加载”，Session 属于有状态、需持久化、带序列化开销的模块，默认不包含在核心中。直接用 map[string]interface{} 模拟 Session 会引发并发写 panic，且无法跨进程共享。
- 官方推荐方案是使用
github.com/gofiber/storage下的适配器（如redis、memcache、badger）配合github.com/gofiber/session - 内存存储（
store := session.New()）仅适合开发调试，重启即丢，且多实例时会话不一致 - Redis 存储需确保连接池配置合理，否则高并发下
GET/SET成为瓶颈；建议启用session.Config{Expiration: 1800}显式控制过期 - Session ID 默认存于 Cookie 中，名称是
session_id，不可直接修改 —— 若需自定义，得 forksession包或改用底层storage自行实现
Fiber 中 Cookie 和 Session 配合使用的典型陷阱
常见错误不是代码写错，而是部署和浏览器行为没对齐：
- 本地开发用 HTTP 但设了
Secure: true→ 浏览器直接拒存 Cookie，控制台无报错，只静默失败 - 前端 Axios/Fetch 未设
credentials: 'include'→ Cookie 不随请求发出，后端收不到session_id - 跨域时后端没配
c.App().Use(func(c *fiber.Ctx) error { c.Set("Access-Control-Allow-Credentials", "true"); return c.Next() })，且前端域名没精确匹配allowedOrigins，导致预检失败 - Session 过期后，
store.Get(c)返回空 session 但不报错，容易忽略判空直接取值，panic 或返回默认数据
最易被忽略的是：Fiber 的 session.Store 在获取 session 时不会自动刷新过期时间，除非你显式调用 s.Save() 或设置 Config{Refresh: true} —— 否则用户活跃但 session 照样到期。
