因为c.SetCookie()接收*http.Cookie指针，不自动补全安全属性，必须手动设置Secure、HttpOnly、SameSite字段，否则默认为零值导致浏览器静默丢弃或不安全。
为什么 c.SetCookie() 不能直接设 Secure/HttpOnly/SameSite？
Echo 的 c.SetCookie() 接收的是 *http.Cookie 指针，它本身不校验或自动补全安全属性；你传进去的 http.Cookie 实例必须手动设置 Secure、HttpOnly、SameSite 字段，否则默认全为零值（即 false / 0），浏览器会当作普通 Cookie 处理。
常见错误是只设了 Value 和 MaxAge，漏掉 Secure: true —— 在 HTTPS 环境下，没这个字段，Chrome/Firefox 会静默丢弃该 Cookie，且不报错，导致“写入成功但读不到”。
-
Secure必须为true才能在 HTTPS 下生效；HTTP 环境下设为true会导致 Cookie 被忽略（开发时容易踩坑） -
HttpOnly设为true后，JS 无法通过document.cookie读取，防 XSS 关键一环 -
SameSite建议用http.SameSiteLaxMode（登录/支付等关键操作可用Strict），避免 CSRF
如何避免 SameSite 和域名配置冲突？
SameSite 行为受 Domain 和 Path 共同影响。比如你设了 Domain: "example.com" 但请求来自 api.example.com，且 SameSite: http.SameSiteLaxMode，那么跨子域 POST 请求可能被拦截。
更隐蔽的问题：本地开发用 localhost 时，Domain 字段不能设为 "localhost"（浏览器不认），也不能留空（会默认为当前 host，但带端口时如 localhost:8080 会被拒绝）。正确做法是：
- 生产环境显式设
Domain: ".example.com"（注意开头的点，表示包含所有子域） - 开发环境保持
Domain为空字符串""，让浏览器自动推导 - 若需跨子域共享 Cookie，
SameSite必须设为http.SameSiteNoneMode，且Secure必须为true（否则现代浏览器直接拒收）
MaxAge 和 Expires 到底该用哪个？
两者功能重叠，但行为不同：MaxAge 是秒数（int），Expires 是绝对时间（time.Time）。浏览器优先看 MaxAge，如果同时存在且冲突，部分浏览器（如 Safari）会忽略 Expires。
实际建议只用 MaxAge，原因明确：
- 避免时区/系统时间误差导致的过期时间漂移
- Echo 中
http.Cookie.MaxAge直接赋整数值即可，比如3600表示 1 小时 - 设为
0或负数，等效于会话级 Cookie（关闭浏览器即失效） - 不要同时设
MaxAge和Expires，尤其不要用time.Now().Add(...).UTC()再去填Expires—— 多余且易出错
Session Cookie 和业务 Cookie 的过期时间怎么协同？
Session 数据（如 Redis 中存的用户 ID）和 Session Cookie（浏览器里的 session_id）是两套生命周期。如果只设 sess.Options.MaxAge = 1800（30 分钟），但 c.SetCookie() 里 MaxAge 设成 86400（24 小时），用户 Cookie 还在，但服务端 session 已销毁，就会出现“能发请求但鉴权失败”的现象。
必须双向对齐：
- 登录态 Cookie 的
MaxAge应 ≤ Session 存储后端的 TTL（如 Redis key 过期时间） - 若用
sessions.NewRedisStore，确保redis.SetEx的过期时间和 Cookie 的MaxAge一致，差几秒都可能引发竞态 - “记住我”场景需额外逻辑：Cookie
MaxAge设长（如 7 天），但每次请求都刷新 Redis 中 session 的 TTL，并重置 Cookie 的过期时间（调用c.SetCookie()覆盖）
最易被忽略的一点：Echo 的 session.Middleware() 默认不会自动刷新 Cookie 过期时间，这个刷新动作必须由业务 handler 显式触发 —— 不做，就等于放任用户拿着一个“僵尸 Cookie”反复撞墙。
