生产环境Cookie必须设置HttpOnly、Secure、SameSite三属性：HttpOnly防XSS读取，Secure强制HTTPS传输，SameSite=Lax防CSRF；缺一可能导致浏览器拒绝发送或JS窃取。
直接用 c.Cookie() 和 c.Cookies() 就能完成基础读写，但生产环境必须注意 HttpOnly、SameSite、Secure 这三个字段的组合逻辑，否则 Cookie 可能被浏览器拒绝发送或 JS 窃取。
设置 Cookie：关键参数不能漏
Fiber 的 c.Cookie() 是封装好的快捷方法，底层调用 fasthttp.SetCookie。它默认不设 HttpOnly 和 Secure，线上部署极易出问题。
-
HttpOnly: true—— 防止 XSS 读取敏感 Cookie（如 session_id、JWT） -
Secure: true—— 强制只在 HTTPS 下发送（开发时可设为false，但上线必须true） -
SameSite: "Lax"或"Strict"—— 防 CSRF，默认""（即浏览器按旧规则处理，不安全） -
MaxAge优先于Expires；设为0表示会话级 Cookie，关闭浏览器即失效
示例：
c.Cookie(&fiber.Cookie{
Name: "session_id",
Value: "abc123",
Path: "/",
Domain: "example.com",
HTTPOnly: true,
Secure: true,
SameSite: "Lax",
MaxAge: 3600,
})
读取 Cookie：别只依赖 c.Cookies()
c.Cookies() 返回所有 Cookie 的 map，但实际业务中往往只需要一个值。更常见的是用 c.Cookies("name") 直接取单个值——它内部做了空值判断，比手动查 map 安全。
- 如果 Cookie 不存在，
c.Cookies("name")返回空字符串，不会 panic - 若需区分“不存在”和“值为空”，得用
c.Get("Cookie")手动解析原始头（不推荐，除非调试） - 注意：JS 设置的 Cookie 若带
HttpOnly，服务端仍可读，但前端 JS 无法访问 —— 这是正常行为，不是 bug
JWT 存 Cookie 时的特殊处理
很多人把 JWT 存进 Cookie，但容易忽略两点：签名验证前必须先读出来，且不能让前端 JS 操作它。
- 务必设
HttpOnly: true和Secure: true，否则 Token 可被 XSS 盗取 - 别用
c.Query("token")或c.FormValue("token")替代 Cookie 读取 —— 这会绕过 SameSite 防护，且暴露在 URL 或表单中 - 若同时支持 Cookie 和 Header 认证（比如兼容移动端），提取逻辑要统一走
extractors.Chain()，而不是混用c.Cookies()和c.Get("Authorization")
跨域场景下 Cookie 不生效？检查这三处
Cross-Origin 请求中 Cookie 失效，90% 是这三个地方配错了：
- 前端 fetch 必须加
credentials: "include"，否则浏览器根本不会发 Cookie - 后端
c.Cookie()必须设Domain（如"example.com"），不能设成"localhost"或带端口（"localhost:3000"无效） -
SameSite不能设为"Strict"（跨域 POST 会被拦截），"Lax"是较稳妥的选择；若需完全放开（如嵌入 iframe），才考虑"None"+Secure: true
SameSite 的语义容易被低估：它不是“要不要发 Cookie”，而是“在什么请求上下文中允许发”。一次看似正常的跳转，可能因 Referer 变化就被拦截。
