golang

Go 入门：Cookie、Session 和一个简单登录状态

登录状态是 Web 开发绕不开的话题。很多初学者一听到 Session，就会把它想成某种神秘机制。其实从 HTTP 角度看，Cookie 是浏览器保存并自动带回服务端的一小段数据；Session 是服务端用这段数据找到用户状态的一种做法。Cookie 在客户端，Session 数据通常在服务端。

plumephp 8 分钟阅读 3673 字

登录状态是 Web 开发绕不开的话题。很多初学者一听到 Session，就会把它想成某种神秘机制。其实从 HTTP 角度看，Cookie 是浏览器保存并自动带回服务端的一小段数据；Session 是服务端用这段数据找到用户状态的一种做法。Cookie 在客户端，Session 数据通常在服务端。

Go 的 net/http 标准库已经提供了 Cookie 读写能力。理解它不难，难的是不要把敏感信息直接塞进 Cookie，也不要忽略过期、删除、安全属性这些细节。

最简单的 Cookie 可以这样写：

func setName(w http.ResponseWriter, r *http.Request) {
	http.SetCookie(w, &http.Cookie{
		Name:     "visitor",
		Value:    "nina",
		Path:     "/",
		HttpOnly: true,
		MaxAge:   3600,
	})
	fmt.Fprintln(w, "cookie set")
}

Name 是键，Value 是值，Path 决定哪些路径会带上这个 Cookie。HttpOnly 表示浏览器里的 JavaScript 不能直接读取它。它不能防止所有攻击，但能降低 XSS 后 Cookie 被脚本偷走的风险。MaxAge 是秒数，3600 表示一小时。

注意 Cookie 必须在响应头写出前设置。如果你先 fmt.Fprintln(w, ...)，再 http.SetCookie，头部可能已经发送，Cookie 就不会生效。

读取时使用 r.Cookie：

func hello(w http.ResponseWriter, r *http.Request) {
	c, err := r.Cookie("visitor")
	if err != nil {
		if errors.Is(err, http.ErrNoCookie) {
			fmt.Fprintln(w, "hello, guest")
			return
		}
		http.Error(w, "bad cookie", http.StatusBadRequest)
		return
	}
	fmt.Fprintf(w, "hello, %s\n", c.Value)
}

没有 Cookie 是正常情况，不应该打 error 日志。很多用户第一次访问、清理浏览器、换设备，都会没有 Cookie。只有格式异常或业务校验失败时，才需要额外处理。

如果你把 user_id=123 放进 Cookie，用户可以自己改成 456。如果把 role=admin 放进去，后果更明显。Cookie 来自客户端，服务端必须把它当成不可信输入。

更常见的做法是：Cookie 里只放一个随机 Session ID，服务端用它查真正的用户状态。

type Session struct {
	UserID    int64
	ExpiresAt time.Time
}

var sessions = struct {
	sync.Mutex
	m map[string]Session
}{m: make(map[string]Session)}

这个内存 map 只适合教学或单进程小工具。生产环境通常会用 Redis、数据库或专门的 Session 存储，因为进程重启后内存会丢，多实例之间也不共享。

生成安全的 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
}

这里用的是 crypto/rand，不是 math/rand。前者适合安全随机，后者适合模拟、抽样、游戏里的非安全随机。RawURLEncoding 生成的字符串不会包含 / 和 +，放在 Cookie 里更省心。

登录时创建 Session

先省略密码校验，只演示 Session 创建流程：

func login(w http.ResponseWriter, r *http.Request) {
	userID := int64(1001)

	id, err := newSessionID()
	if err != nil {
		http.Error(w, "create session", http.StatusInternalServerError)
		return
	}
	expires := time.Now().Add(2 * time.Hour)

	sessions.Lock()
	sessions.m[id] = Session{UserID: userID, ExpiresAt: expires}
	sessions.Unlock()

	http.SetCookie(w, &http.Cookie{
		Name:     "sid",
		Value:    id,
		Path:     "/",
		HttpOnly: true,
		SameSite: http.SameSiteLaxMode,
		Expires:  expires,
		Secure:   true,
	})
	fmt.Fprintln(w, "logged in")
}

Secure: true 表示只在 HTTPS 下发送。线上应该开启；本地开发如果没有 HTTPS，可以临时关掉。SameSite 能降低跨站请求携带 Cookie 的机会，普通后台和内容站常用 Lax。如果你在做跨站嵌入或第三方登录回调，需要更细地理解 SameSite 策略。

中间件读取登录状态

登录后的接口需要从 Cookie 找 Session：

func currentUserID(r *http.Request) (int64, bool) {
	c, err := r.Cookie("sid")
	if err != nil {
		return 0, false
	}

	sessions.Lock()
	s, ok := sessions.m[c.Value]
	sessions.Unlock()
	if !ok {
		return 0, false
	}
	if time.Now().After(s.ExpiresAt) {
		return 0, false
	}
	return s.UserID, true
}

过期检查不能只依赖 Cookie 的 Expires。浏览器可能不按你预期保存，攻击者也可以构造请求。服务端存储里的过期时间才是最终依据。

用它保护页面：

func profile(w http.ResponseWriter, r *http.Request) {
	userID, ok := currentUserID(r)
	if !ok {
		http.Error(w, "please login", http.StatusUnauthorized)
		return
	}
	fmt.Fprintf(w, "user id: %d\n", userID)
}

退出不是只让前端跳转登录页。服务端要删除 Session，浏览器也要删除 Cookie。

func logout(w http.ResponseWriter, r *http.Request) {
	if c, err := r.Cookie("sid"); err == nil {
		sessions.Lock()
		delete(sessions.m, c.Value)
		sessions.Unlock()
	}

	http.SetCookie(w, &http.Cookie{
		Name:     "sid",
		Value:    "",
		Path:     "/",
		MaxAge:   -1,
		HttpOnly: true,
		Secure:   true,
		SameSite: http.SameSiteLaxMode,
	})
	fmt.Fprintln(w, "logged out")
}

删除 Cookie 时 Name 和 Path 要和写入时一致，否则浏览器可能删的是另一个路径下的 Cookie。这个细节很容易漏。

清理过期 Session

内存 Session map 如果不清理，会慢慢变大。可以启动一个后台清理任务：

func cleanupSessions(ctx context.Context) {
	ticker := time.NewTicker(10 * time.Minute)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			now := time.Now()
			sessions.Lock()
			for id, s := range sessions.m {
				if now.After(s.ExpiresAt) {
					delete(sessions.m, id)
				}
			}
			sessions.Unlock()
		}
	}
}

如果服务已经有统一的后台任务管理，就把它接进去。不要在每个请求里顺手清理一大堆过期数据，那会让某些用户请求突然变慢。

小结

Cookie 是浏览器和服务端之间的状态载体，Session 是服务端管理登录状态的一种方式。入门项目里可以用内存 map 理解流程，但要知道它不适合多实例生产环境。

安全上记住几条：不要信任 Cookie 值，不要把角色和敏感资料明文放进 Cookie；Session ID 用 crypto/rand 生成；线上开启 HttpOnly、Secure、合理的 SameSite；退出时同时删除服务端状态和浏览器 Cookie。把这些基础做好，后面接 Redis、数据库或成熟认证框架都会顺很多。

常见问题与解答

Session 数据应该存什么？

只存标识用户身份的最小信息（如用户 ID、角色）。不要把用户密码、敏感个人信息、大额配置放在 Session 里。Session 数据量越小，查询越快，安全风险也越低。

有。单个 Cookie 值通常不能超过 4KB。如果 Session 数据很大，不要全放在 Cookie 里（那会让 Cookie 变成巨型 token）。只在 Cookie 里存 Session ID，数据存在服务端。

设置 Domain 属性：

&http.Cookie{
    Name:   "sid",
    Value:  sessionID,
    Domain: ".example.com",
    Path:   "/",
}

这样 api.example.com 和 www.example.com 都能读取同一个 Cookie。

防止 Session 固定攻击

登录成功后应该重置 Session ID，防止攻击者预先设置 Session ID 再诱导用户登录：

func upgradeSession(w http.ResponseWriter, r *http.Request, store SessionStore, oldID string, userID int64) error {
    store.Delete(oldID)
    newID, _ := generateSessionID()
    store.Save(newID, Session{UserID: userID, ExpiresAt: time.Now().Add(2 * time.Hour)})
    setSessionCookie(w, newID, time.Now().Add(2*time.Hour))
    return nil
}

RBAC 简单实现

基于角色的访问控制可以在 Session 中存储角色：

type Session struct {
    UserID int64
    Role   string
    ExpiresAt time.Time
}

func requireRole(store *SessionStore, role string, next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        sess, ok := store.Get(r)
        if !ok || sess.Role != role {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }
        next.ServeHTTP(w, r)
    })
}

实践练习

完成以下练习以巩固所学知识：

  1. 阅读 Go 官方文档相关章节
  2. 编写一个完整的示例程序
  3. 为示例程序编写单元测试
  4. 使用 go test 和 go benchmark 验证实现
  5. 尝试优化内存分配和运行时间

推荐阅读

真实项目用例

在实际团队协作中，下面是几个推荐的工作流：

代码审查清单

  • 函数是否处理了所有 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 相关面试，以下概念是高频考点：

  1. goroutine 和线程的区别
  2. channel 的缓冲和非缓冲用法
  3. defer 的执行顺序和与返回值的关系
  4. map 的并发不安全性和解决方案
  5. interface 的隐式实现和类型断言
  6. slice 的底层数组和 append 机制
  7. GC 的基本原理和调优参数
  8. context 的使用场景和超时控制
  9. error 的包装和 errors.Is/errors.As
  10. 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 泄漏。

常见坑与避坑指南

  1. 不要信任用户输入：无论表单、JSON、Cookie 还是 HTTP Header，都当作不可信数据处理，做校验和转义。
  2. 资源要释放：文件、数据库连接、HTTP 响应体都要及时关闭。defer 是一个好习惯。
  3. 不要忽略错误：即使 defer file.Close() 可能返回错误，至少记录日志。完全忽略错误是 bug 的温床。
  4. 不要滥用 goroutine：每个 goroutine 都要有明确的退出路径。使用 sync.WaitGroup 和 context 管理生命周期。
  5. 不要硬编码配置：端口、路径、超时时间、密钥都应该从配置读取，让程序适应不同环境。
  6. 不要过早优化：先让代码正确和可读，再用 benchmark 和 profile 找到真正的热点。

延伸阅读与实践建议

读完本文后，建议完成以下实践：

  1. 把文中所有示例代码在自己的机器上跑一遍
  2. 给示例代码补充错误分支的测试用例
  3. 尝试基于本文内容构建一个小型完整项目
  4. 在 review 他人的 Go 代码时，检查本文提到的边界是否被覆盖
  5. 订阅 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 语言的设计简洁但不简单，掌握它需要持续的实践和反思。希望这篇文章能成为你学习道路上的一个可靠参考。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「golang」更多文章

  1. 熔断、降级与限流：Go 微服务韧性设计完全指南
  2. 事件溯源与 CQRS 在 Go 中的实践：复杂业务系统的架构升级
  3. TinyGo 嵌入式开发与物联网实战：微控制器编程完全指南