是，Cookie值含未编码的空格、分号等非法字符会导致c.Cookie()解析失败并返回ErrNoCookie；必须用c.Request().Header.Get("Cookie")获取原始头，再手动split分号、trim空格、url.QueryUnescape解码。
Cookie 值里含空格或分号就解析失败？用 c.Cookie() 之前先看原始头
Echo 的 c.Cookie("name") 不是“取值”，而是调用 http.Request.Cookie() 做标准解析——它严格遵循 RFC 6265。如果 Cookie 值里有未编码的空格、分号、逗号或等号（比如前端直接 document.cookie = "token=abc def"），c.Cookie() 会返回 http.ErrNoCookie，哪怕 Header 里明明有那条记录。
真正读原始字符串得绕过封装：c.Request().Header.Get("Cookie")，然后手动按 ; 拆分、= 分割、strings.TrimSpace() 清理，再做正则或 url.QueryUnescape() 解码。别依赖 c.Cookie() 来判断“是否存在”，它只对格式合规的值有效。
- 前端写 Cookie 必须用
encodeURIComponent()编码值，尤其是 JWT 或 base64 字符串 - 服务端设 Cookie 时，
http.Cookie.Value字段本身不自动编码，你得自己url.PathEscape()或url.QueryEscape() - 浏览器对
Set-Cookie头里的非法字符会静默截断，导致后半段丢失——用 Chrome DevTools 的 Application → Cookies 面板确认实际存入值
http.Cookie 的 Expires 和 MaxAge 冲突会导致 Cookie 立即失效
设置 Cookie 时若同时指定 Expires（绝对时间）和 MaxAge（秒数），不同浏览器行为不一致：Chrome 优先认 MaxAge，Safari 可能忽略 MaxAge 直接按 Expires 算。更麻烦的是，如果 Expires 是过去的时间戳（比如时钟不同步或硬编码了旧时间），浏览器会立刻丢弃该 Cookie，c.Cookie() 永远拿不到。
正确做法是二者只选其一：MaxAge 更可靠（相对时间，不受客户端时钟影响），且 Echo 的 c.SetCookie() 要求传入完整 *http.Cookie 实例，必须显式设 MaxAge: 3600 或 Expires: time.Now().Add(1 * time.Hour)，不能留零值。
-
MaxAge: 0表示“删除 Cookie”，不是“永不过期” -
MaxAge: -1是无效值，部分 Go 版本会 panic - 测试时用
curl -v -b "name=value" http://localhost:8080绕过浏览器，验证服务端是否真的发出了合法Set-Cookie头
Secure、HttpOnly、SameSite 字段缺失或错配，让 Cookie 在特定场景下“消失”
Cookie 不是“设了就一定能读到”。比如你在 HTTP 环境下调用 c.SetCookie(&http.Cookie{Secure: true})，浏览器会拒绝存储；又或者前端是 https://app.example.com，但后端域名设成 example.com，而没配 Domain 字段，Cookie 就不会随请求带上。
SameSite 是最容易被忽略的坑：SameSite: http.SameSiteStrictMode 下，从 https://evil.com 发起的跳转请求根本不会携带 Cookie；SameSite: http.SameSiteNoneMode 则必须配 Secure: true，否则现代浏览器直接拒收。
- 开发环境用
localhost时，Domain字段必须留空，填"localhost"会被视为非法 -
HttpOnly: true后，JS 无法读取（document.cookie里看不到），但c.Cookie()仍能取到——这是正常行为，不是 bug - 调试时用
c.Request().Header.Get("Cookie")查原始头，比依赖c.Cookie()更早暴露字段配置问题
Cookie 值反序列化失败，panic 比 400 更隐蔽
很多人把 JSON 字符串直接塞进 Cookie：c.SetCookie(&http.Cookie{Value: `{"user_id":123,"role":"admin"}`})。这本身合法，但后续用 json.Unmarshal([]byte(cookie.Value), &u) 时，如果值被浏览器截断、URL 解码出错或含不可见控制字符，就会 panic 而非返回 error——因为中间件链里没 recover。
安全做法是：所有需要反序列化的 Cookie 值，先做基础校验：strings.TrimSpace(cookie.Value) 非空、json.Valid([]byte(cookie.Value)) 为 true，再进 Unmarshal。别假设 Cookie 是“可信输入”，它和 query 参数一样来自客户端。
- 敏感字段（如用户 ID）建议单独存，不要打包进大 JSON，降低解析失败概率
- 用
base64.RawURLEncoding.EncodeToString()包一层再存 Cookie，避免特殊字符干扰 - 生产环境务必在全局 panic 恢复中间件里捕获
json.SyntaxError类型，否则一次非法 Cookie 可能导致整个服务 crash
关键点不在“怎么解析”，而在“解析前怎么确认它值得解析”——原始头内容、字段组合、传输上下文，三者缺一不可。浏览器对 Cookie 的处理远比文档写的苛刻，靠 c.Cookie() 返回 error 就终止逻辑，大概率漏掉真实问题。
