必须使用c.SetCookie()写入Cookie，因其线程安全且校验合法；手动调用http.SetCookie()会导致并发Header冲突；传参须为*http.Cookie指针，Secure字段需按环境设true/false；同名Cookie后写覆盖前写；读取时须判空并校验Value、Domain、Path。
Cookie写入必须用c.SetCookie()，不能手动调用http.SetCookie()
并发场景下手动调用http.SetCookie()会导致Header写冲突：多个goroutine同时操作http.ResponseWriter.Header()，可能覆盖彼此的Set-Cookie头，最终只生效最后一个。Echo封装了线程安全的c.SetCookie()，内部已做同步处理，且会校验http.Cookie字段合法性（比如MaxAge和Expires不同时设）。常见错误是绕过框架直接写Header，尤其在中间件或异步逻辑里——哪怕只写一次，也埋下并发隐患。
c.SetCookie()传参必须是完整*http.Cookie实例，不是键值对
传错类型会导致静默失败或panic：c.SetCookie()只接受*http.Cookie指针，传map[string]string或结构体字面量会编译报错；传nil则运行时panic。正确做法是显式初始化：
cookie := &http.Cookie{
Name: "session_id",
Value: "abc123",
Path: "/",
MaxAge: 3600,
HttpOnly: true,
Secure: true, // 生产环境必须开
SameSite: http.SameSiteLaxMode,
}
注意Secure字段：本地开发用HTTP时需设false，否则浏览器直接丢弃；上线HTTPS后必须为true，否则Cookie无法发送。
并发读写同一Cookie名时，值以最后一次c.SetCookie()为准
没有“合并”或“追加”语义，多次调用c.SetCookie()同名Cookie，浏览器只认最后一条。典型踩坑点：
- 多个中间件（如鉴权、日志）各自尝试设置
user_idCookie，结果后者覆盖前者 - handler里先写
theme=dark，又在defer里删掉（MaxAge: -1），但因执行顺序不确定，可能删不掉 - 异步goroutine里调用
c.SetCookie()——echo.Context不保证跨goroutine安全，必须在主请求goroutine中完成所有Cookie操作
解决方案：统一由业务handler集中管理Cookie写入，中间件只读不写；删除操作务必用MaxAge: -1或Expires: time.Unix(0, 0)，避免依赖Value: ""这种无效写法。
读取Cookie时c.Cookie("name")返回*http.Cookie，注意判空和字段有效性
并发环境下，即使写入成功，读取也可能返回nil或http.ErrNoCookie，因为Cookie可能被前端清除、过期，或域名/路径不匹配。直接解引用cookie.Value前必须检查：
cookie, err := c.Cookie("session_id")
if err != nil {
if errors.Is(err, http.ErrNoCookie) {
// Cookie不存在，走未登录流程
return c.Redirect(http.StatusFound, "/login")
}
return err
}
// 此时cookie非nil，但Value仍可能为空字符串
if cookie.Value == "" {
return c.String(http.StatusBadRequest, "empty session_id")
}
特别注意Domain和Path：如果写入时设了Domain: ".example.com"，读取时请求Host必须是sub.example.com或example.com才可见；Path: "/api"写的Cookie，在/auth/login路径下读不到。
echo.Context只活到handler返回，但Cookie一旦发出就脱离框架控制；任何想“动态修改已发出Cookie”的尝试，本质都是下一次请求的覆盖操作。 
