destroysession() 应在退出登录路由中响应写出前调用，立即重定向；它销毁会话实例、清除服务端数据并过期客户端 cookie，而 delsession 仅删除键值，不终止会话生命周期。
Beego 中 DestroySession 的正确调用时机
退出登录的本质是清除用户会话，Beego 并不提供单独的 “logout” 路由或中间件，必须手动调用 DestroySession 并配合重定向。常见错误是只清空 SetSession 数据但没销毁底层 session 实例，导致下次请求仍能读到旧 session ID。
实际操作中应确保：
-
DestroySession()在响应写出前调用（即不能在Finish()之后） - 调用后立即执行
Redirect，避免后续逻辑意外读写 session - 若启用了 session 自动保存（默认开启），
DestroySession会自动触发 session 数据删除和 cookie 清除
典型退出路由实现（controllers/logout.go）
Beego 路由需显式注册，且控制器方法要处理 session 销毁与跳转。以下是最简可靠写法：
func (c *MainController) Logout() {
c.DestroySession() // 必须调用，不只是删 key
c.Ctx.SetCookie("beegosessionID", "", -1, "/") // 可选：主动覆盖 cookie，增强兼容性
c.Redirect("/login", 302)
}
注意：c.DestroySession() 内部已调用 session.SessionDestroy 并清理响应头中的 session cookie，但某些浏览器或反向代理下 cookie 过期可能延迟，补一句 SetCookie 更稳妥。
为什么 DelSession 不等于退出登录
DelSession("user_id") 或 DelAllSession() 只是删除 session 存储里的键值，不会销毁 session 实例本身，也不会清除客户端 cookie。用户下次请求仍携带原 beegosessionID，Beego 会复用该 ID 加载一个空 session —— 表面“登出”，实则 session 未真正终结。
关键区别：
-
DestroySession()→ 销毁 session 实例 + 删除服务端数据 + 设置 cookie 过期 -
DelSession(key)→ 仅从当前 session 对象里删一个字段，不影响生命周期 -
SessionRegenerateID()→ 换 ID，但旧 ID 仍有效直到过期，不适用于退出场景
退出后仍能访问受保护路由？检查中间件顺序
如果退出后还能打开 /admin 等页面，大概率是鉴权中间件没在 DestroySession 后及时拦截。Beego 的 Prepare 方法在 action 执行前运行，但 logout action 本身必须先完成销毁再返回，否则中间件可能读到残留 session。
典型错误模式：
- 在
Prepare里判断登录态 → 正确，但 logout action 里没调DestroySession - 把鉴权逻辑写在
Get/Post内部 → 退出时漏掉，导致 logout 成功但其他接口仍可直连 - 使用了自定义 session provider（如 redis）但未配置
gcMaxLifetime，旧 session 数据残留数小时
session 机制依赖服务端存储与客户端 cookie 协同失效，任一端没清理干净，退出就不彻底。
