必须用 c.SetCookie() 和 c.Cookie() 操作 Cookie，因其确保时机、位置正确及属性合规；手动调用 http.SetCookie 或改 Header 会导致静默失效、浏览器忽略或报错。
直接用 c.SetCookie() 和 c.Cookie()，别碰 http.SetCookie 或手动改 Header —— 否则 Cookie 会静默失效或被浏览器忽略。
为什么不能手动调用 http.SetCookie？
Echo 的 Context 封装了响应写入流程，c.SetCookie() 会在正确时机、正确位置写入 Set-Cookie 头；而直接调用 http.SetCookie(c.Response(), cookie) 会绕过框架校验，可能在 Header 已 flush 后才执行，导致报错或无效果。
- 常见错误现象：
http: multiple response.WriteHeader calls或浏览器收不到 Cookie - 即使没报错，也常出现 Cookie 写入成功但后续请求不携带（因 Domain/Path 不匹配或 Secure 属性缺失）
-
c.SetCookie()会自动处理Expires与MaxAge的互斥逻辑，手动构造容易同时设两者，被 Chrome/Firefox 忽略
怎么安全地读写一个登录态 Cookie？
以用户 token 存入 Cookie 为例，重点是属性配置和错误处理：
- 写入时必须初始化
*http.Cookie实例，不能只传 name/value：cookie := &http.Cookie{ Name: "auth_token", Value: "eyJhbGciOiJIUzI1Ni...", Path: "/", Domain: "example.com", // 注意：localhost 下需留空或设为 "" HttpOnly: true, Secure: true, // 生产环境必须开启 MaxAge: 3600, SameSite: http.SameSiteLaxMode, } - 读取必须检查 error：
cookie, err := c.Cookie("auth_token")；若 key 不存在，err == http.ErrNoCookie，不是nil - 不要用
c.Cookies()遍历找 token —— 效率低且无法利用 HttpOnly 保护
Cookie 和 Session 混用时最容易踩的坑
Session 数据本身不存于 Cookie，而是靠 Cookie 存 session ID；但很多人误以为“写了 Session 就等于写了 Cookie”，结果发现登录后刷新就掉会话。
- Session 中间件必须提前注册：
e.Use(session.Middleware(sessions.NewFilesystemStore("/tmp", []byte("session-key-32-bytes-long"))))，放在任何路由定义之前 - Session name（如
"user_session"）必须全局一致：写入用sess.Options.Name = "user_session"，读取也得用同一个字符串，大小写敏感 - Cookie 的
Domain和Path必须与 Session 中间件中配置的完全一致，否则浏览器不会回传该 Cookie - 如果用 Redis 存储 Session，
MaxAge要和sess.Options.MaxAge协同：前者控制客户端 Cookie 过期，后者控制服务端数据 TTL，建议设为相同值
真正麻烦的从来不是写一行 c.SetCookie()，而是确保每次请求的 Cookie 属性（Domain、Path、Secure、SameSite）在前后端、开发/生产环境之间完全对齐 —— 少一个斜杠、多一个点，都可能导致会话断裂。
