Martini 是 Go 语言早期轻量级的 Web 框架，其设计哲学是组合小型中间件来完成请求处理。在实际项目中，不少团队发现用户登录成功后，下一次请求却读不到 Session 里的信息，表现为频繁掉线或身份校验失败。这种问题通常不是业务代码错误，而是对 Martini 的 Session 机制理解不深、配置不完整所导致。
一、Martini Session 机制的基本原理
Martini 核心仓库并不包含 Session 功能，官方推荐通过 martini-contrib/sessions 扩展包来实现。该包基于 gorilla/sessions 封装，提供了 sessions.Session() 中间件。当请求进入时，中间件会从 Cookie 或指定存储中反序列化出会话对象，并注入到处理器参数里。
需要明确的是，Session 对象本身只在当前请求生命周期内有效。如果存储后端是内存映射，且 Martini 实例重启或多进程部署，原有会话数据就会消失。另外，许多开发者忽略了会话写入的时机：修改 Session 后必须调用 session.Save(r, w)，否则修改仅存在于内存对象中，不会被持久化到存储层，下一次请求自然无法读取。
二、常见导致无法跨请求保持的原因
1. 中间件未正确挂载
有些项目在路由分组中才使用 Session，但中间件只在局部注册，导致部分请求没有经过会话解析。正确方式是在全局 m.Use() 中注册，确保所有请求都能初始化 Session。
以下代码展示了错误与正确用法的区别：
package main
import (
"github.com/go-martini/martini"
"github.com/martini-contrib/sessions"
)
func wrong() {
m := martini.New()
// 错误：只在某个路由里使用，其他请求无 Session
m.Get("/login", func(session sessions.Session) string {
session.Set("uid", 1)
return "ok"
})
}
func right() {
m := martini.New()
// 正确：全局挂载，所有请求均可用
store := sessions.NewCookieStore([]byte("my-secret-key"))
m.Use(sessions.Sessions("my_session", store))
m.Get("/login", func(session sessions.Session) string {
session.Set("uid", 1)
return "ok"
})
}
2. 存储引擎选择不当
默认的内存存储 NewMemoryStore 在单进程调试时可用，但生产环境如果采用多副本部署，请求被负载均衡到不同节点，内存数据不共享，Session 必然丢失。此时应切换为 Redis 等集中式存储。
使用 Redis 存储的示例代码如下，需要引入 github.com/martini-contrib/sessions 与 Redis 适配包：
package main
import (
"github.com/go-martini/martini"
"github.com/martini-contrib/sessions"
"github.com/boj/redistore"
)
func main() {
m := martini.New()
store, _ := redistore.NewRediStore(10, "tcp", "127.0.0.1:6379", "", []byte("session_secret"))
defer store.Close()
m.Use(sessions.Sessions("my_session", store))
m.Get("/set", func(session sessions.Session) string {
session.Set("user", "tom")
return "saved"
})
m.Get("/get", func(session sessions.Session) string {
val := session.Get("user")
if val == nil {
return "empty"
}
return val.(string)
})
m.Run()
}
三、必须显式保存会话修改
在 gorilla/sessions 的设计中，Session 的写入是延迟的，只有调用 Save 方法才会将最新数据编码并写回存储或 Cookie。Martini 的封装并没有自动在请求结束时保存，因此遗漏保存是跨请求失效的高发原因。
下面代码演示了安全的使用方式，每次设置后都立即保存：
m.Post("/login", func(req *http.Request, res http.ResponseWriter, session sessions.Session) string {
session.Set("authed", true)
session.Set("name", req.FormValue("name"))
// 显式保存，确保跨请求可读
session.Save(req, res)
return "login success"
})
如果在一个请求中多次修改 Session，只需在逻辑结束前调用一次 Save 即可，不必每次 Set 都保存，但仍要确认最终有保存动作，否则所有改动都会随请求结束而丢弃。
四、密钥与 Cookie 安全配置
NewCookieStore 或 Redis 存储初始化时传入的字节切片是加密密钥，用于保证 Cookie 不被篡改。如果每次启动程序都随机生成密钥，那么重启后旧 Session 无法解密，表现为数据丢失。因此密钥应写于配置文件中固定下来。
同时，可通过 store.Options 设置 MaxAge、HttpOnly 等属性，控制会话有效期与安全传输。示例如下：
store := sessions.NewCookieStore([]byte("fixed_secret_123"))
store.Options(sessions.Options{
MaxAge: 3600 * 12,
Path: "/",
HttpOnly: true,
})
m.Use(sessions.Sessions("my_session", store))
合理配置这些参数，既能避免浏览器关闭即失效的困惑，也能降低 XSS 窃取会话的风险，从侧面保障跨请求会话的稳定性。
五、排查与验证建议
当遇到 Session 不保持时，可依次检查：中间件是否全局注册、存储是否跨进程共享、是否调用了 Save、密钥是否固定。还可以写一个简单的双路由测试，一个写Session一个读Session，用 curl 携带 Cookie 验证，快速定位是哪一层出问题。
总之，Martini 中 Session 跨请求失效并不是框架缺陷，而是配置与用法细节未到位。理清中间件加载、存储后端、显式保存与密钥管理四个要点，就能让会话数据在多次请求间可靠传递。