应使用 bcrypt 哈希密码并配合 redis 管理带过期的 session Token；bcrypt 需用 Defaultcost（12），存储哈希字符串（≥60 字符）；cookie 必设 Secure、httpOnly、SameSite 和 MaxAge；登录态校验须统一中间件，登出需同步失效 Redis key 与 Cookie。
用 bcrypt 做密码哈希，别碰 md5 或 sha256
明文存密码是红线，但随便选个哈希函数也不行。bcrypt 内置盐值和可调慢速因子，能有效抵抗暴力破解。go 标准库不提供，得用 golang.org/x/crypto/bcrypt。
常见错误：直接 bcrypt.GenerateFromPassword([]byte(pwd), 4) —— 4 太低，实际建议用 bcrypt.DefaultCost（目前是 12），否则容易被 GPU 破解。
- 注册时：用
bcrypt.GenerateFromPassword得到哈希字符串，存进数据库字段（长度至少 60 字符） - 登录比对时：用
bcrypt.CompareHashAndPassword，传入数据库取回的哈希值和用户提交的明文密码，返回nil才算通过 - 别自己拼接盐值、别用
base64编码哈希结果——bcrypt输出本身就是可存储的 ASCII 字符串
用 http.Cookie + Secure/HttpOnly 管理登录态
Session ID 不该放在 URL 或 localStorage 里。最简可行方案是服务端生成随机 token（如 uuid.NewString()），存进 Redis（带过期时间），再通过 http.SetCookie 写入客户端 Cookie。
关键配置漏掉一个就可能被窃取：
立即学习“go语言免费学习笔记（深入）”；
-
Secure: true—— 仅 https 传输（开发时若用 HTTP，得设Secure: false，但上线必须关掉） -
HttpOnly: true—— js 无法读取，防 xss 盗 cookie -
SameSite: http.SameSiteStrictMode或http.SameSiteLaxMode—— 防 csrf -
MaxAge: 3600（秒）比Expires更可靠，尤其跨时区场景
别把用户 ID 或权限直接塞进 cookie 值里签名了事——token 本身只是 lookup key，所有敏感信息必须查服务端存储。
写中间件校验登录态，别在每个 handler 里重复 req.Cookie("session_id")
登录态验证逻辑应该统一收口。典型做法是写一个 authMiddleware 函数，接收 http.Handler，返回包装后的 handler。
要点：
- 从
req.Cookie("session_id")取值，if err != nil就直接http.Redirect到登录页或返回 401 - 查 Redis 得到对应 user ID 后，用
context.WithValue注入到req.Context()，后续 handler 用req.Context().Value(authKey)拿用户信息 - 别用全局 map 存 session——并发不安全，且没过期机制
- 如果用 gin/echo，优先用它们自带的 middleware 机制，别自己造 context 传递轮子
处理并发登录踢出、登出失效，Redis 的 DEL 要配 EXPIRE
用户点击“退出”时，不能只删前端 cookie，必须让后端 token 失效。简单删 Redis key 是对的，但要注意时序：
- 登出 handler 中先
DEL session_id，再清除客户端 cookie（MaxAge: 0） - 如果支持“单设备登录”，新登录时就得先
DEL旧 session key；注意 Redis 的DEL是原子操作，但得确保 key 名包含用户维度（如session:uid_123），而不是只用随机字符串 - 别依赖 cookie 过期自动清理——用户可能一直不关浏览器，得靠 Redis 的 TTL 主动淘汰
- 如果用 JWT 代替 session，务必维护一个
jwt_blacklist集合（哪怕只存 jti），否则无法主动登出
最易忽略的是：Redis key 过期时间和 cookie MaxAge 必须对齐，差几秒都可能导致“登出后还能刷出首页”。