应使用c.Cookie("name")安全读取单个Cookie，返回*http.Cookie和error；若不存在则err为http.ErrNoCookie，不可忽略；禁用c.Request().Cookies()，因Echo已禁用该路径且结果不可靠。
用 c.Cookie() 读单个 Cookie，别碰 http.Request.Cookies
直接调用 c.Cookie("sessionid") 是唯一安全的读取方式。它返回 *http.Cookie 和 error，如果 Cookie 不存在，err 就是 http.ErrNoCookie —— 不是 nil，不能只判空。常见错误是忽略这个 error，结果一访问不存在的 key 就 panic。
绝对不要手动从 c.Request().Cookies() 拿，Echo 已禁用该路径：框架内部可能已修改或延迟解析原始 Cookie 头，自己去扒 http.Request 得到的切片要么为空、要么和实际逻辑不一致。
-
c.Cookie("token")返回的是完整http.Cookie结构体，包含Value、HttpOnly、Secure等字段，不只是字符串值 - 若只需值，写
cookie, err := c.Cookie("name"); if err == nil { val := cookie.Value }，别省略err判断 - 名称大小写敏感，
"SessionID"和"sessionid"是两个不同 Cookie
c.Cookies() 遍历全部，适合调试但慎用于生产逻辑
c.Cookies() 返回 []*http.Cookie，能拿到当前请求里所有匹配域名和路径的 Cookie 实例。它不校验是否过期、是否被浏览器标记为 HttpOnly，只是原样反射出已送达的原始数据。
这方法适合开发期打印日志查问题，比如确认前端是否真发了某个 Cookie；但别在核心业务里靠遍历找 key —— 效率低，且容易漏掉大小写或空格导致匹配失败。
- 遍历时注意
cookie.Value可能是 URL 编码过的，服务端一般不需要再解码（Echo 内部已处理），除非你手动拼接过非标准格式 - 某些代理或 CDN 可能过滤掉部分 Cookie（尤其含特殊字符的），
c.Cookies()拿到的列表可能比浏览器开发者工具里看到的少 - 不要用它替代
c.Cookie(name)做关键读取，因为没做存在性封装，要自己写循环 + 字符串比较，易出错
读取失败的三个高频原因
不是代码写错，而是配置或环境链路断了。90% 的 “读不到 Cookie” 问题出在这三处：
- 前端没发：浏览器开发者工具 Network → 请求头里没有
Cookie:字段，说明域名、路径或SameSite配置不匹配，或者用了fetch但没设credentials: 'include' - 服务端没认：Echo 路由没注册中间件，或
session.Middleware()注册顺序错了（必须在e.GET之前），导致上下文缺失基础解析能力 - Cookie 属性冲突：
SecureCookie 在 HTTP 环境下不会被浏览器发送；Domain设成.example.com但请求发向api.example.com时，若没显式配对，也会被丢弃
从 cookie.Value 取值后，类型断言要加防护
Cookie 的 Value 是字符串，但如果你把它当 Session ID 去查后端存储，后续流程里很容易做类型转换。例如 sess.Values["user_id"] 是 interface{}，直接赋给 int64 变量会 panic。
这不是 c.Cookie() 的问题，而是下游使用习惯导致的运行时崩溃。真实项目中，建议统一用 strconv.ParseInt() 或 json.Unmarshal() 显式转换，而不是依赖 Go 的隐式类型断言。
- 哪怕确定是数字，也写
if idStr, ok := cookie.Value.(string); ok { id, _ := strconv.ParseInt(idStr, 10, 64) } - 如果 Cookie 值是 JSON 片段（如
{"uid":123,"role":"admin"}），必须用json.Unmarshal([]byte(cookie.Value), &v)，不能直接断言结构体 - 任何从 Cookie 来的数据，都默认不可信 —— 即使加了
HttpOnly，也不能跳过服务端校验逻辑
c.Cookie("x") 调用背后，至少横跨四层信任边界。 
