c.Cookie()仅解析并URL解码请求中的Cookie值，不加密、不解密、不验证签名；读取后若需解密，须手动使用写入时相同的算法和密钥处理。
直接读取客户端 Cookie 不等于“解密”——Cookie 本身不是加密数据，而是明文传输的字符串（除非你手动加密过）。Gin 的 c.Cookie() 只是解析 HTTP 请求头中的 Cookie 字段，提取指定键的值；它不处理、不解密、也不验证任何加密逻辑。
为什么 c.Cookie() 返回的是原始字符串？
Gin 的 c.Cookie(name) 底层调用的是 http.Request.Cookies()，再遍历匹配 Name。浏览器发来的 Cookie 是形如 auth_token=abc123; user_prefs=%7B%22lang%22%3A%22zh%22%7D 的 URL 编码字符串，c.Cookie() 会自动做一次 url.QueryUnescape，但仅此而已。
- 它不会自动 Base64 解码（除非你存的时候手动 Base64，读的时候也得手动）
- 它不会自动 AES/DES 解密（Gin 完全不介入加解密流程）
- 它不校验签名，不验证完整性（比如 HMAC 或 JWT signature）
如何安全地“解密”自定义加密 Cookie？
如果你在写入时用了加密（比如 AES-GCM），那读取后必须用相同密钥和算法手动解密。常见错误是：只加密没解密，或密钥不一致导致 panic 或乱码。
- 写入时示例：
c.SetCookie("auth_token", encryptedValue, 3600, "/", "example.com", true, true) - 读取后必须显式调用解密函数，例如：
plain, err := decryptAES(encrypted) - 务必检查
err—— 解密失败通常返回crypto/aes: invalid key size或cipher: message authentication failed - 不要把密钥硬编码在 handler 里，应从环境变量或 secret store 加载
c.Cookie() 常见失败原因和绕过技巧
调用 c.Cookie("token") 返回 http: named cookie not present 并不总意味着 Cookie 不存在，可能只是参数不匹配。
- 路径不一致：写入时用了
path="/api"，读取时请求路径是/→ 无法命中 - 域名不一致：本地开发用
"localhost"，但请求来自127.0.0.1→ 浏览器视为不同域 -
Secure=true但走 HTTP → 浏览器根本不会发送该 Cookie - 想读
HttpOnlyCookie？可以读，HttpOnly只防 JS 访问，不影响 Go 后端读取
真正需要“解密”的场景其实是 JWT 或签名 Cookie
很多团队把 JWT 存进 Cookie 当作 token，这时所谓“解密”其实是 jwt.Parse() 验证签名 + 解析 payload。注意：
- 别用
ParseUnverified()，跳过签名验证等于裸奔 - 检查
exp字段是否过期（time.Now().After(claims.ExpiresAt.Time)） - 如果用了
SameSite=Strict，跨站 POST 请求可能不带 Cookie，导致解析失败 - JWT payload 里的字段（如
user_id）仍是明文，敏感信息仍需服务端二次校验权限
真正的难点不在读取，而在写入时的加密策略与读取时的上下文一致性——密钥管理、算法版本、编码方式、路径/域名/Secure 标志，漏掉任何一个，都会让“解密”变成不可预测的字符串或 panic。
