martini 应用中使用 `martini-contrib/sessions` 时，session 数据在请求间丢失，通常因中间件执行顺序不当或响应未正确提交 cookie 导致；本文详解正确配置 cookie store、确保中间件顺序、避免提前终止请求等关键修复步骤。
在 Martini 框架中，Session 跨请求失效是一个常见但易被忽视的问题。从你提供的代码来看，逻辑本身（如 session.Set() 和 session.Get()）并无语法错误，但实际运行中 /session 接口返回空结构体，说明 Session 数据未能持久化到后续请求——根本原因几乎总是 HTTP 响应未携带有效的 Set-Cookie 头，导致浏览器无法保存或回传 session ID。
✅ 正确的 Session 中间件使用前提
Martini 的 sessions.Sessions() 是一个 全局中间件（Global Middleware），必须通过 m.Use(...) 在路由注册前启用，且需确保：
- Session store（如 CookieStore）密钥足够安全（生产环境勿用硬编码明文）；
- 浏览器同源策略与请求路径匹配（例如：Cookie Path 默认为 /，若应用部署在子路径如 /app/，需显式设置 store.Options(sessions.Options{Path: "/app/"})）；
- 最关键：所有写入 Session 的 handler 必须返回响应（即不能 panic、未返回值、或被前置中间件拦截中断）。
你当前的 /login 处理函数存在两个高危问题：
- defer conn.Close() 放置错误：sql.Open 返回的是连接池，不应在每次请求中 defer Close()（这会立即关闭池），应改为 defer stmt.Close() 后，在函数末尾显式调用 conn.Close()（或更佳：使用 defer func(){...}() 包裹资源释放，但推荐用 database/sql 的标准模式：连接池由 sql.DB 自动管理，无需手动 Close）；
- log.Fatal(err) 导致进程崩溃：一旦登录失败（如密码错误触发 QueryRow().Scan() 返回 sql.ErrNoRows），log.Fatal(err) 会终止整个进程，不仅中断当前请求，更导致 Session Cookie 根本未生成/未写入 HTTP 响应头 —— 浏览器收不到 Set-Cookie，自然无法在 /session 请求中回传 session ID。
✅ 修复后的 /login 示例（关键修正）
m.Get("/login", binding.Bind(LoginForm{}), func(r render.Render, session sessions.Session, form LoginForm) string {
// ✅ 正确使用数据库连接（连接池复用，无需 defer conn.Close）
conn, err := sql.Open("sqlite3", "ocdns.db")
if err != nil {
log.Printf("DB open failed: %v", err)
return "DB error"
}
defer conn.Close() // ✅ 此处 defer 安全：conn 是本次请求获取的句柄（实际是池中连接）
stmt, err := conn.Prepare(`
SELECT user_id, username, name_first, name_last, role, team_id
FROM User
WHERE username = ? AND password = ?
LIMIT 1;
`)
if err != nil {
log.Printf("Prepare failed: %v", err)
return "SQL prepare error"
}
defer stmt.Close()
var id, username, name_first, name_last, role, team_id string
err = stmt.QueryRow(form.Username, form.Password).Scan(
&id, &username, &name_first, &name_last, &role, &team_id,
)
if err != nil {
if err == sql.ErrNoRows {
log.Printf("Login failed for user: %s", form.Username)
return "Bad" // ✅ 不 panic，确保响应发出
}
log.Printf("Query error: %v", err)
return "DB query error"
}
// ✅ 安全写入 Session
session.Set("id", id)
session.Set("username", username)
session.Set("name_first", name_first)
session.Set("name_last", name_last)
session.Set("role", role)
session.Set("team_id", team_id)
// ✅ 强制刷新 Session（可选但推荐，确保 Cookie 立即写入响应头）
session.Save()
log.Printf("Login OK for user: %s", username)
return "OK"
})✅ 补充验证与最佳实践
- 强制 session.Save()：虽然 martini-contrib/sessions 在 handler 结束时会自动保存，但在复杂流程（如重定向前、或嵌套中间件）中显式调用 session.Save() 可避免意外丢失。
- 检查响应头：用 Chrome DevTools → Network → 查看 /login 响应的 Headers → Response Headers，确认存在类似 Set-Cookie: my_session=xxxxxx; Path=/; HttpOnly 的字段。
-
Cookie 安全选项（生产必备）：
store := sessions.NewCookieStore([]byte("your-32-byte-secret-key-here")) store.Options(sessions.Options{ Path: "/", MaxAge: 86400, // 24h HttpOnly: true, Secure: true, // 仅 HTTPS 传输（部署到 HTTPS 环境时启用） SameSite: http.SameSiteLaxMode, }) m.Use(sessions.Sessions("my_session", store)) - 避免 log.Fatal / panic：Martini 中任何未捕获的 panic 或 os.Exit() 都会导致响应中断，Session 无法落盘。
✅ 总结
Session 跨请求失效 ≠ Session 代码写错，而是 HTTP 协议层契约未履行：服务器必须在首次写入 Session 时，通过 Set-Cookie 告诉浏览器“请记住这个 ID”；浏览器则需在后续请求中通过 Cookie 头回传它。只要确保：
- sessions.Sessions() 全局启用且配置合理；
- 所有写 Session 的 handler 正常返回（无 panic、无 log.Fatal）；
- 数据库等资源清理不干扰响应流；
- （可选）显式调用 session.Save()；
你的 Session 就能稳定工作。调试时优先检查网络面板中的 Cookie 交互，而非仅关注 Go 代码逻辑。
