中间件本身不处理cookie读写，因其仅负责注册和拦截，真正读写必须在路由处理器中调用c.setcookie()或c.cookie()，并依赖正确配置的session中间件来安全存取会话数据。
不能靠中间件“处理”Cookie数据——中间件只负责注册和拦截，真正读写 Cookie 必须在路由处理器里用 c.SetCookie() 或 c.Cookie()，且必须配合正确配置的 session 中间件才能安全存取会话级数据。
为什么中间件本身不处理 Cookie 读写
中间件（如 session.Middleware()）的作用是统一注入 session 实例到 echo.Context，它不解析、不修改、也不生成 Cookie。你看到的“设置 Cookie”动作，实际发生在 handler 函数内部：c.SetCookie() 才真正调用 http.SetCookie() 写入响应头；c.Cookie("name") 才从 r.Cookies() 中提取原始 Cookie 值。
- 中间件无法访问
echo.Context的完整生命周期，它只在请求进入和响应发出前各执行一次 - 直接在中间件里调用
c.SetCookie()会覆盖后续 handler 的设置，且无业务上下文支撑 - 若想做全局 Cookie 注入（如埋点 ID），应使用自定义中间件 +
c.Request().Header检查 +c.Response().Header().Set()，但注意这不属于标准 Cookie 流程
session.Middleware() 是唯一推荐的 Cookie 会话方案
手动拼 http.Cookie{} 并调用 c.SetCookie() 虽然能设值，但无法解决签名、过期校验、HttpOnly、SameSite 等关键问题。生产环境必须用 github.com/labstack/echo-contrib/session 提供的中间件封装。
- 初始化时密钥长度必须 ≥ 32 字节，否则启动 panic：
crypto/aes: invalid key size - 开发可用
cookiestore.NewCookieStore([]byte("32-byte-secret-key-here"))，但该 store 将 session 数据全量加密后存在 Cookie 里，有 4KB 大小限制和性能隐患 - 生产务必切换为 Redis 存储：
redisstore.NewRedisStore(...)，避免 Cookie 膨胀和客户端篡改风险 - 注册顺序很重要：必须在
e.Use(...)中早于所有依赖 session 的路由，否则session.Get()会 panic
c.SetCookie() 和 c.Cookie() 的典型误用场景
这两个函数适合处理非会话类轻量 Cookie（如语言偏好、主题色），但极易出错：
-
c.SetCookie()不自动设置Path和Domain，漏设会导致前端 JS 读不到或跨子域失效 - 未显式设置
MaxAge时，浏览器按 Session Cookie 处理，关浏览器即丢，不是“7 天有效期” -
c.Cookie("name")返回*http.Cookie，但若客户端没发该 Cookie，返回nil，直接取.Value会 panic - 跨域请求下，若没配
AllowCredentials: true且前端fetch(..., {credentials: 'include'})，Cookie 根本不会发送
跨域 + Cookie 的组合配置要点
仅靠 session.Middleware() 无法解决跨域 Cookie 问题，必须联动 CORS 配置：
- CORS 中间件的
AllowCredentials必须设为true，否则浏览器禁止携带 Cookie -
AllowOrigins不能为"*"，必须明确列出可信域名（如[]string{"https://app.example.com"}） - Cookie 的
Domain选项需匹配主域（如.example.com），且服务端响应头Access-Control-Allow-Origin必须与之严格一致 - 前端 fetch 请求必须带
{credentials: 'include'}，否则 Cookie 不参与请求
这些细节一旦漏掉一个，session.Get() 就拿不到 session，或者 Cookie 在 Chrome/Firefox 下静默失效——问题往往出在配置联动，而非代码逻辑本身。
