Fiber 中不能直接调用 Cookie::get()，必须通过 c.Cookies().Get("key") 读取；需检查名称大小写、Path 路径、Secure 配置，并在中间件中校验签名、有效期及黑名单，最后将可信数据存入 c.Locals。
中间件里直接调 Cookie::get() 会失败？先确认 Fiber 版本和 Cookie 配置
Fiber 本身不提供 Cookie::get() 这种 Laravel 风格的静态方法——那是 Laravel 的语法，Fiber 没这玩意儿。你在 Fiber 中读 Cookie，必须通过 *fiber.Ctx 实例调用 c.Cookies() 或 c.Cookies()["key"]；但更推荐用 c.Cookies().Get("key")，它自动处理缺失键、空值和 URL 解码。
常见错误现象：代码写成 Cookie::get("token")，编译直接报 undefined: Cookie；或者用了 c.Cookies()["token"] 却没判空，导致 panic。
-
c.Cookies()返回的是map[string]string，底层是解析Cookie请求头后拆分得到的键值对，不校验签名、不加密、不防篡改 - 如果你依赖 Laravel 那种“加密 Cookie”，Fiber 默认不支持，得自己加中间件做解密或换用
fiber.New()+ 自定义ctx.Locals存解密后数据 - 开发时若前端发请求用的是
http://localhost:3000，而服务端 Cookie 配置了Secure: true，浏览器根本不会发送该 Cookie，c.Cookies()必然为空——这不是代码问题，是协议不匹配
为什么 c.Cookies().Get("xxx") 返回空？检查 Cookie 名称、大小写和路径
Fiber 的 c.Cookies().Get() 是纯字符串匹配，区分大小写，且不自动处理路径（Path=/api 的 Cookie 在 /user 路由下不可见）。
典型误判场景：Set-Cookie: auth_token=abc123; Path=/admin; HttpOnly，你在 /user/profile 的中间件里调 c.Cookies().Get("auth_token")，结果是空字符串，不是 error，容易当成“用户没登录”。
- 用浏览器 DevTools 的 Application → Cookies 查看当前域名下实际存在的 Cookie 列表，确认 key 名拼写、大小写、domain 和 path 是否匹配当前请求
- 如果 Cookie 是服务端用
c.Cookie(&fiber.Cookie{...})设置的，注意Name字段必须和读取时传入的 key 完全一致（比如设置时是Name: "AuthToken"，就读"AuthToken"，不是"auth_token"） - Fiber 不自动 fallback 到子路径，
Path=/才能全局可读；若设了Path=/api，只有/api/xxx及其子路径能读到
需要校验签名或加密 Cookie？别绕过 c.Cookies()，用中间件预处理
Fiber 默认不验证 Cookie 签名，所以 c.Cookies().Get() 拿到的是原始字符串。如果你从 Laravel 或其他框架迁移，习惯用加密 Cookie 存 session ID 或 token，直接读原始值等于裸奔。
正确做法是在中间件里手动解密+校验，再把可信数据存进 c.Locals，后续 handler 统一从 c.Locals 取，而不是反复解析和校验。
- 示例流程：
c.Cookies().Get("session_id") → base64 decode → AES decrypt → HMAC verify → parse JSON → c.Locals.Set("user_id", id) - 别在每个路由 handler 里重复这套逻辑，封装成一个
authMiddleware，统一处理并提前 return 401 - 注意：Fiber 的
*fiber.Ctx是复用对象，c.Locals是 request-scoped map，安全可靠；不要往全局变量或闭包里存用户数据 - 如果用第三方库如
gorilla/securecookie，确保密钥不硬编码，生产环境从环境变量加载
读到 Cookie 后马上校验有效期和业务状态，别只看“有没有”
很多中间件卡在“读到了就放行”，结果用户拿着过期的 refresh_token 一直刷接口，服务端不返回 401，前端无限重试，日志里全是 token expired 却没人处理。
真正有用的鉴权中间件，至少要检查三件事：是否存在、是否未过期、是否被注销（查 Redis 黑名单）。缺一不可。
- Cookie 值本身不含时间戳，有效期靠
MaxAge或Expires响应头控制，服务端需额外存一份签发时间和过期时间（比如 JWT payload 里的exp） - 不要用
time.Now().Before(expireTime)就完事，要考虑服务器时钟漂移，建议预留 5 秒容错窗口 - 如果业务允许“单点登录踢出”，每次读 Cookie 后必须查一次 Redis，确认该 token 是否已被
DEL—— 这步常被跳过，导致登出失效 - 最后，所有校验失败都应明确返回状态码（如 401 或 403），别静默
c.Next()，否则下游 handler 会基于脏数据执行
