正确读取普通 Cookie 应优先调用 c.Cookie("name")，它自动解码并处理异常；若遇 http: named cookie not present，需排查域名/路径不匹配、Secure/SameSite 策略导致浏览器未发送，而非服务端解析失败。
如何用 gin.Context 正确读取普通 Cookie 值
直接调用 c.Cookie() 是最常用方式，但它会自动解码 URL 编码并校验签名（如果 Cookie 被 SetSecureCookie 设置过），不适用于手动设置或第三方写入的原始 Cookie。
常见错误是遇到 http: named cookie not present 却以为没传过来——其实可能是前端没带 SameSite=None; Secure（HTTPS 环境下），或域名/路径不匹配导致浏览器根本没发。
- 用
c.Request.Header.Get("Cookie")可看到原始字符串，适合调试是否送达 - 普通读取推荐
c.Cookie("session_id")，它内部调用http.Request.Cookie()并处理了常见异常 - 若需忽略签名校验（比如兼容旧系统写的 Cookie），改用
c.Request.Cookie("token")，但要自己处理nil和url.QueryUnescape
解析带 HttpOnly / Secure / SameSite 的 Cookie 为什么失败
HttpOnly 只影响 JavaScript 访问，Gin 后端完全不受限；真正卡住的是 Secure 和 SameSite 策略——它们控制浏览器「是否发送」该 Cookie，而非服务端能否解析。
典型现象：本地 http://localhost:8080 能读到 auth_token，部署到 Nginx + HTTPS 后突然返回 nil。大概率是前端设 Cookie 时用了 Secure 但没配 SameSite=Lax 或 None，导致跨站请求被拦截。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查响应头：
Set-Cookie: user=abc; Path=/; Secure; SameSite=Lax—— 这个在 HTTPS 下才生效 - Gin 默认不强制 Secure，必须显式传参：
c.SetCookie("theme", "dark", 3600, "/", "example.com", true, true)，最后两个true分别对应Secure和HttpOnly - 开发时若用 HTTP，把
Secure设为false，否则 Chrome 直接丢弃
处理 Base64 编码或 JSON 格式的 Cookie 值
Cookie 值本质是字符串，Gin 不会自动反序列化。如果你存的是 base64(json) 或纯 JSON，得手动解码，否则得到的是乱码或 panic。
例如前端执行 document.cookie = "profile=" + btoa(JSON.stringify({id:123,name:"a"}))，后端不能直接当字符串用。
- 先用
c.Cookie("profile")拿到 base64 字符串 - 再用
base64.StdEncoding.DecodeString()解码，注意捕获base64.CorruptInputError - 接着用
json.Unmarshal()转结构体，别忘了检查err != nil—— 常见于前端多写了逗号或字段名大小写不一致 - 更稳妥的做法：统一用
url.QueryEscape替代 base64，体积小、无特殊字符风险
多个同名 Cookie 怎么区分 domain/path？
HTTP 协议允许同一名称、不同 domain/path 的 Cookie 共存（如 user 在 .example.com 和 api.example.com 各设一个），但 c.Cookie() 只返回第一个匹配项（按 RFC，浏览器按 path 长度降序发送，根路径最靠前）。
这意味着你可能误读了错误 domain 的值，尤其在微服务共域场景下（app.example.com 和 admin.example.com 共享 .example.com 的 Cookie）。
- 用
c.Request.Cookies()获取全部*http.Cookie切片，遍历比对cookie.Domain和cookie.Path - 注意
Domain字段在 Go 的http.Cookie中是空字符串（浏览器不回传 Domain），只能靠请求 Host 推断 - 真正可靠的隔离方式是命名区分：
app_user/admin_user，而不是依赖 domain
time.Now().Add() 用错单位（比如传秒没转成 time.Second），会导致浏览器立刻过期。 
