做 Web 应用时，登录态是绕不开的话题。很多初学者会问：用户登录后，是不是把用户 ID 放到 Cookie 里？Session 和 Cookie 有什么区别？退出登录时要删什么？这些问题看似简单，但如果边界没想清楚，很容易留下安全隐患。
Cookie 是浏览器保存并随请求发送的小段数据。Session 通常是服务端保存的一份状态，浏览器只拿一个 session ID。最常见的设计是：登录成功后，服务端生成随机 session ID，把它写入 Cookie；之后请求带着 Cookie，服务端用 session ID 查用户身份。
生成 Session ID
Session ID 必须随机且不可预测：
func newSessionID() (string, error) {
var b [32]byte
if _, err := rand.Read(b[:]); err != nil {
return "", err
}
return base64.RawURLEncoding.EncodeToString(b[:]), nil
}
不要用用户 ID、时间戳或自增数字当 session ID。攻击者如果能猜到别人的 ID，就能冒充登录。随机数要用 crypto/rand，不是 math/rand。
服务端保存 Session
入门示例可以用内存 map：
type Session struct {
UserID int64
ExpiresAt time.Time
}
type SessionStore struct {
mu sync.RWMutex
sessions map[string]Session
}
func NewSessionStore() *SessionStore {
return &SessionStore{sessions: make(map[string]Session)}
}
保存：
func (s *SessionStore) Save(id string, session Session) {
s.mu.Lock()
defer s.mu.Unlock()
s.sessions[id] = session
}
读取：
func (s *SessionStore) Get(id string) (Session, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
session, ok := s.sessions[id]
if !ok || time.Now().After(session.ExpiresAt) {
return Session{}, false
}
return session, true
}
内存 store 适合单进程示例。生产环境如果有多个实例，通常会把 session 放到 Redis、数据库或使用签名 token。本文先讲基础模型。
设置 Cookie
登录成功后：
func setSessionCookie(w http.ResponseWriter, sessionID string, expires time.Time) {
http.SetCookie(w, &http.Cookie{
Name: "sid",
Value: sessionID,
Path: "/",
Expires: expires,
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteLaxMode,
})
}
HttpOnly 表示 JavaScript 不能读取这个 Cookie，降低 XSS 后偷取 Cookie 的风险。Secure 表示只在 HTTPS 下发送。SameSite 可以减少跨站请求带上 Cookie 的机会。生产环境应尽量开启这些属性。
开发环境如果没有 HTTPS，Secure: true 会导致浏览器不发送 Cookie。可以根据配置区分本地和生产，但不要忘记生产环境打开。
从请求读取登录态
中间件读取 Cookie：
func RequireLogin(store *SessionStore, next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
cookie, err := r.Cookie("sid")
if err != nil {
http.Error(w, "login required", http.StatusUnauthorized)
return
}
session, ok := store.Get(cookie.Value)
if !ok {
http.Error(w, "login required", http.StatusUnauthorized)
return
}
ctx := context.WithValue(r.Context(), userIDKey{}, session.UserID)
next.ServeHTTP(w, r.WithContext(ctx))
})
}
context.WithValue 要谨慎使用，适合放请求范围的小信息，比如当前用户 ID。key 不要用普通字符串，避免包之间冲突：
type userIDKey struct{}
业务 handler 可以取出：
func CurrentUserID(ctx context.Context) (int64, bool) {
id, ok := ctx.Value(userIDKey{}).(int64)
return id, ok
}
退出登录
退出时要删除服务端 session，并让浏览器 Cookie 过期：
func (s *SessionStore) Delete(id string) {
s.mu.Lock()
defer s.mu.Unlock()
delete(s.sessions, id)
}
func clearSessionCookie(w http.ResponseWriter) {
http.SetCookie(w, &http.Cookie{
Name: "sid",
Value: "",
Path: "/",
MaxAge: -1,
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteLaxMode,
})
}
只删 Cookie 不删服务端 session，旧 session ID 如果被别人拿到仍可能可用。只删服务端 session 不清 Cookie，用户浏览器还会继续带一个无效 ID。两边都处理最清楚。
Cookie 里能不能直接放用户 ID
可以，但要非常谨慎。普通 Cookie 用户可以自己修改。如果你把 user_id=1 放进去，攻击者可能改成 user_id=2。除非你对 Cookie 做了签名或加密，否则不要把可信身份直接放在客户端。
Session ID 的好处是它本身没有业务含义。服务端查不到就无效，过期了也无效。即使攻击者看到一个随机 ID，也很难猜到另一个有效 ID。
测试登录中间件
测试未登录：
func TestRequireLoginRejectsMissingCookie(t *testing.T) {
store := NewSessionStore()
handler := RequireLogin(store, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
t.Fatal("next should not be called")
}))
req := httptest.NewRequest(http.MethodGet, "/me", nil)
rec := httptest.NewRecorder()
handler.ServeHTTP(rec, req)
if rec.Code != http.StatusUnauthorized {
t.Fatalf("status = %d", rec.Code)
}
}
测试已登录：
func TestRequireLoginAllowsValidSession(t *testing.T) {
store := NewSessionStore()
store.Save("abc", Session{UserID: 7, ExpiresAt: time.Now().Add(time.Hour)})
handler := RequireLogin(store, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
id, ok := CurrentUserID(r.Context())
if !ok || id != 7 {
t.Fatalf("user id = %d, ok = %v", id, ok)
}
w.WriteHeader(http.StatusNoContent)
}))
req := httptest.NewRequest(http.MethodGet, "/me", nil)
req.AddCookie(&http.Cookie{Name: "sid", Value: "abc"})
rec := httptest.NewRecorder()
handler.ServeHTTP(rec, req)
}
小结
Cookie 是浏览器携带数据的机制，Session 是服务端保存登录状态的模型。常见做法是 Cookie 里只放随机 session ID，服务端通过它查用户身份。Cookie 应设置 HttpOnly、Secure、SameSite，退出登录时同时删除服务端 session 和客户端 Cookie。
入门阶段不要急着自己设计复杂 token。先把 session ID、服务端存储、过期时间、退出登录和测试路径写清楚，已经能覆盖很多普通 Web 应用。
常见问题与解答
Session 和 JWT 怎么选？
Session 适合传统 Web 应用，服务端控制力强，可以立刻作废。JWT 适合分布式和移动应用，不需要服务端存储，但撤销困难。入门项目建议先用 Session 理解状态管理。
SameSite 选什么模式？
- Strict：最严格，完全禁止跨站携带 Cookie
- Lax：允许安全的跨站 GET 请求携带（如点击链接）
- None：允许所有跨站请求携带，但必须配合 Secure
普通后台和内容站点用 Lax 最合适。
内存 Session 有什么限制？
进程重启后数据丢失，多实例之间不共享，没有持久化。适合单进程学习和小型工具。生产环境应使用 Redis、数据库或共享缓存。
Session 存储到 Redis
type RedisSessionStore struct {
client redis.UniversalClient
prefix string
ttl time.Duration
}
func (s *RedisSessionStore) Save(ctx context.Context, id string, sess Session) error {
data, _ := json.Marshal(sess)
return s.client.Set(ctx, s.prefix+id, data, s.ttl).Err()
}
func (s *RedisSessionStore) Get(ctx context.Context, id string) (Session, error) {
data, err := s.client.Get(ctx, s.prefix+id).Result()
if err == redis.Nil {
return Session{}, fmt.Errorf("session not found")
}
if err != nil {
return Session{}, err
}
var sess Session
json.Unmarshal([]byte(data), &sess)
return sess, nil
}
Cookie 安全加固
func setSecureCookie(w http.ResponseWriter, name, value string, expires time.Time) {
http.SetCookie(w, &http.Cookie{
Name: name,
Value: value,
Path: "/",
Expires: expires,
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteLaxMode,
})
}
线上务必开启 Secure 和 HttpOnly，SameSite 推荐 Lax。
实践练习
完成以下练习以巩固所学知识：
- 阅读 Go 官方文档相关章节
- 编写一个完整的示例程序
- 为示例程序编写单元测试
- 使用
go test和go benchmark验证实现 - 尝试优化内存分配和运行时间
推荐阅读
- Go 官方博客: https://go.dev/blog/
- Effective Go: https://go.dev/doc/effective_go
- Go by Example: https://gobyexample.com/
- Go 标准库文档: https://pkg.go.dev/std
真实项目用例
在实际团队协作中，下面是几个推荐的工作流：
代码审查清单
- 函数是否处理了所有 error 返回值
- 并发代码是否有明确的退出路径和 WaitGroup
- 用户输入是否经过校验和清洗
- 敏感配置是否通过环境变量或加密存储注入
- 测试是否覆盖了正常路径和至少一个错误路径
- 日志是否包含足够的上下文信息但不泄露敏感数据
- 接口设计是否符合最小接口原则
CI/CD 集成建议
- 每次提交前运行
go fmt ./... - CI 中运行
go vet ./...和golangci-lint run - 单元测试使用
go test -race ./...检测数据竞争 - 关键路径的 benchmark 加入回归测试
- 使用
go mod verify确保依赖完整性
性能调优检查点
- 使用 pprof 分析 CPU 和内存使用
- 关注 benchmark 的 allocs/op，减少高频路径的堆分配
- 检查数据库查询是否使用索引
- 确认外部 HTTP 调用有合理的超时设置
- 缓存热点数据，但注意缓存一致性和过期策略
面试高频考点
如果你正在准备 Go 相关面试，以下概念是高频考点：
- goroutine 和线程的区别
- channel 的缓冲和非缓冲用法
- defer 的执行顺序和与返回值的关系
- map 的并发不安全性和解决方案
- interface 的隐式实现和类型断言
- slice 的底层数组和 append 机制
- GC 的基本原理和调优参数
- context 的使用场景和超时控制
- error 的包装和 errors.Is/errors.As
- sync.Mutex vs sync.RWMutex vs atomic
掌握这些概念意味着你具备了独立开发 Go 服务的基础能力。继续在实际项目中磨练，你会越来越熟悉 Go 的工程风格和最佳实践。
常见问题（FAQ）
Q: 这个特性在实际项目中真的有用吗？
A: 是的。本文介绍的技术来源于真实后端开发场景。无论是标准库工具还是工程实践，在日常服务开发中都会反复用到。
Q: Go 版本会影响示例代码吗？
A: 本文代码主要针对 Go 1.20+ 编写。较新版本（如 1.22、1.23）的语法可能有微调，但核心概念保持不变。如有版本差异，文中会特别说明。
Q: 学习 Go 应该先学标准库还是直接上框架？
A: 强烈建议先学标准库。框架是对标准库的封装和扩展。只有理解了标准库的能力边界，才能正确选择和使用框架，也才能在框架出问题时快速定位。
Q: 代码里的错误处理为什么都是显式的 if err != nil？
A: 这是 Go 的设计哲学。显式错误处理让失败路径清晰可见，不会隐藏在任何 try-catch 之后。习惯了之后，你会发现这种写法实际上降低了排查错误的难度。
Q: 并发相关代码怎么测试？
A: 使用 Go 内置的 -race 标志检测数据竞争：go test -race ./...。结合 sync.WaitGroup 和 context.WithTimeout 编写有退出路径的并发测试，避免 goroutine 泄漏。
常见坑与避坑指南
- 不要信任用户输入：无论表单、JSON、Cookie 还是 HTTP Header，都当作不可信数据处理，做校验和转义。
- 资源要释放：文件、数据库连接、HTTP 响应体都要及时关闭。
defer是一个好习惯。 - 不要忽略错误：即使
defer file.Close()可能返回错误，至少记录日志。完全忽略错误是 bug 的温床。 - 不要滥用 goroutine：每个 goroutine 都要有明确的退出路径。使用
sync.WaitGroup和context管理生命周期。 - 不要硬编码配置：端口、路径、超时时间、密钥都应该从配置读取，让程序适应不同环境。
- 不要过早优化：先让代码正确和可读，再用 benchmark 和 profile 找到真正的热点。
延伸阅读与实践建议
读完本文后，建议完成以下实践：
- 把文中所有示例代码在自己的机器上跑一遍
- 给示例代码补充错误分支的测试用例
- 尝试基于本文内容构建一个小型完整项目
- 在 review 他人的 Go 代码时，检查本文提到的边界是否被覆盖
- 订阅 Go 官方博客，关注语言演进和最佳实践更新
参考资源
- Go 官方网站：https://go.dev/
- Go 标准库文档：https://pkg.go.dev/std
- Go by Example：https://gobyexample.com/
- Effective Go：https://go.dev/doc/effective_go
- Go 常见问题：https://go.dev/doc/faq
- Go 项目实战社区案例和开源项目源码
本文力求在讲解技术细节的同时兼顾工程实用性。Go 语言的设计简洁但不简单，掌握它需要持续的实践和反思。希望这篇文章能成为你学习道路上的一个可靠参考。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。