直接用 http.SetCookie() 无法安全实现会话，因其仅写入原始 Cookie，无签名、不校验篡改、不处理过期；攻击者可篡改值（如 "isLogin": "false" → "true"），服务端无法察觉。
为什么直接用 http.SetCookie() 无法安全实现会话
因为 http.SetCookie() 只是写入原始 Cookie，不带签名、不校验篡改、不自动处理过期逻辑。攻击者可手动修改 Cookie 值（比如把 "isLogin": "false" 改成 "true"），服务端毫无察觉。Echo 默认也不解析或验证任何 session ID 字段——它压根不知道你在存什么。
session.Middleware() 必须配合 gorilla/sessions.Store 实例
中间件本身只是个“管道”，真正干活的是你传进去的 Store。常见错误是只导入 echo-contrib/session 却漏掉 gorilla/sessions，导致编译失败或运行时 panic：
- 必须显式
go get github.com/gorilla/sessions（即使echo-contrib/session间接依赖它） - 密钥长度不能少于 32 字节，否则启动报错：
crypto/aes: invalid key size -
sessions.NewCookieStore([]byte("..."))仅适合开发；生产环境必须换sessions.NewRedisStore()或sessions.NewPostgreSQLStore() - 别用
echo.Context.SetCookie()手动塞 session ID——它绕过中间件，没签名也没 HttpOnly 控制
读写 session 的正确姿势：用 session.Get() + sess.Save()
每次请求中，session.Get("my_session_name", c) 返回一个带上下文绑定的 *sessions.Session 对象，不是全局单例。关键点：
- session 名字（如
"user_session"）必须前后一致，登录存和后续读取要用同一个字符串 -
sess.Options要显式设置：Path、MaxAge、HttpOnly: true、SameSite: http.SameSiteLaxMode（别依赖默认值） -
sess.Values是map[interface{}]interface{}，只能存可序列化类型（string/int/bool/struct 等），不能存函数或 channel - 必须调用
sess.Save(c.Request(), c.Response())才真正落 Cookie；漏掉这句 = 白写
OAuth2 场景下 state 必须走 session 存储
第三方登录最常踩的坑：把 state 放 query 参数或 localStorage，结果被 CSRF 劫持。正确做法是：
- 生成：用
crypto/rand.Read()拿 32 字节随机数，再hex.EncodeToString() - 存：写进 session，key 为
"oauth_state"，并设MaxAge: 300（5 分钟） - 比对：回调 handler 中用
subtle.ConstantTimeCompare()校验，成功后立刻sess.Delete("oauth_state") - 绝对不要在
state里塞业务参数（如next=/admin）——它只防重放，不传数据
Session 不是黑盒，每个环节都得亲手控制签名、存储、过期和清理，漏掉任意一环，安全就塌一半。
