购物车数据应存 Redis 而非 Session；Session 仅存 user_id 用于身份识别，购物车用 cart:{user_id} 为 key 存 Redis Hash 结构，支持原子增删、跨设备合并与扩容。
购物车数据该存在 Session 还是 Redis？
Session 本身只是个 ID，真正存数据的地方得你自己定。Go 默认的 http.Session 后端用的是内存，重启就丢，根本不能用于电商购物车；哪怕你换成了基于 Redis 的 session 存储，也只适合存用户登录态、CSRF token 这类轻量信息——购物车商品多、更新频繁、还要支持跨设备合并，直接塞进 session 数据结构里会拖慢所有请求。
正确做法是：Session 只管用户身份（比如 session.Values["user_id"]），购物车数据单独用 Redis 做主存储，Key 设计为 cart:，这样读写解耦、可监控、能扩容。
- 别把商品列表 JSON 序列化后塞进
session.Set("cart", data)，这是最常见也最危险的误用 - 如果用户未登录，用临时
cart:guest_存，登录后再合并到真实cart: - Redis 不要设永不过期，用
EXPIRE统一设 7 天，避免僵尸购物车占内存
用 Go 操作 Redis 实现购物车增删改查
别手写连接池或反复 redis.NewClient()，用 github.com/redis/go-redis/v9 并全局复用一个 *redis.Client 实例。购物车操作本质是 Hash 结构的增删改：每个商品用 sku_id 当 field，数量当 value，这样天然去重、单次操作原子。
示例：添加商品
立即学习“go语言免费学习笔记（深入）”；
ctx := context.Background()
key := fmt.Sprintf("cart:%d", userID)
_, err := rdb.HIncrBy(ctx, key, skuID, int64(quantity)).Result()
if err != nil {
// 注意：这里不是 "不存在 key 就失败"，HIncrBy 会自动创建 key
}
// 别用 SET + GET + JSON 解析再改——性能差且并发不安全
- 删除商品用
rdb.HDel(ctx, key, skuID)，不是DEL key全删 - 查全部用
rdb.HGetAll(ctx, key)，返回map[string]string，注意 value 是字符串，需strconv.Atoi - 清空购物车用
rdb.Del(ctx, key)，别循环HDel，太慢
并发场景下加购物车数量错乱怎么办？
用户狂点“+1”，后端多个请求同时读旧值、加 1、写回，结果只加了一次。这不是 Redis 问题，是你没用对命令。别用 HGet + strconv.Atoi + HSet 三步走，必须用原子命令。
- 加减用
rdb.HIncrBy(ctx, key, skuID, delta)，delta 可正可负，Redis 保证原子性 - 设上限（比如最多 99 件）得在应用层判断：先
HGet当前值，再HIncrBy，但要用 Lua 脚本封装成原子操作，否则仍有竞态 - 如果真需要复杂逻辑（如库存校验 + 加购 + 记日志），那就加分布式锁，Key 用
lock:cart:，但别锁整个购物车，只锁单个sku_id
Session ID 和 Redis Key 怎么安全关联？
别把用户 ID 明文写进 Cookie，也别用 session.ID() 当购物车 Key——Session ID 可能被窃取，攻击者就能删你购物车。必须绑定用户身份，且服务端验证。
- 登录成功后，把
user_id写进 session：session.Set("user_id", userID)，并设session.Options.HttpOnly = true - 每次购物车接口，先从 session 里取
userID := session.Values["user_id"]，为空则拒掉，不许 fallback 到 cookie 或 header 里的任意字段 - Redis Key 必须基于用户 ID 构造，禁止拼接任何客户端可控参数，防止 Key 注入（比如
cart:1; DEL cart:*）
最难绷的是：很多人把购物车当成“临时数据”随便处理，但只要用户点了“加入购物车”，它就已是订单生命周期的起点——库存锁定、优惠计算、甚至风控打标，都从这一刻开始。Redis 里那行 HIncrBy 不是玩具命令，是业务契约的第一行落款。
