购物车数据结构推荐用 map[string]*CartItem 配合 []string 记录顺序；需统一 ID 类型、合并重复商品（按 ProductID+SkuID 判断）、删除时同步更新 map 和顺序切片，并用 sync.Mutex 保证并发安全。
购物车数据结构该用 map 还是 slice？
直接用 map[string]*CartItem 最省事，但要注意：商品 ID 作为 key 时，string 类型必须严格一致（比如 "123" 和 123 字符串化后不同），且无法保证添加顺序。若需按加入时间排序展示，得额外维护一个 []string 记录 ID 序列；若只是快速查改删，map 更合适。
常见错误是把 CartItems 设为 map[uint64]*CartItem 却在 HTTP 请求中接收字符串 ID，导致查不到——务必统一 ID 类型或做显式转换。
- 用
map[string]*CartItem：适合大多数 Web 场景，配合 JSON API（ID 通常为字符串） - 用
[]*CartItem：适合需要保序、频繁遍历、不常按 ID 查找的场景 - 混合用法更稳妥：
type Cart struct { Items map[string]*CartItem Order []string // ID 顺序列表 }
添加商品时如何避免重复叠加数量？
用户点两次“加入购物车”，应合并为一条记录并累加 Quantity，而不是插入两条。关键逻辑在于：先查是否存在相同 ProductID（和规格标识如 SkuID），存在则更新数量，否则新建。
容易忽略的是规格维度——同一商品不同颜色/尺寸应视为不同条目。所以判断重复不能只看 ProductID，还得比对 SkuID 或 Options 哈希值。
- 检查是否存在：
if item, ok := cart.Items[cartItemKey]; ok { item.Quantity += req.Quantity } -
cartItemKey推荐拼接：fmt.Sprintf("%s:%s", req.ProductID, req.SkuID) - 数量上限建议校验：
if item.Quantity > 999 { return errors.New("quantity exceeds limit") }
删除商品为什么有时删不干净？
典型问题是只删了 map 中的条目，却忘了从 Order 切片中移除对应 ID，导致后续遍历时 panic 或漏渲染。另一个坑是用 delete(cart.Items, id) 后没同步清理 Order，再调用 GetItems() 时顺序错乱或包含 nil 指针。
安全删除必须两步走：先从 Order 中移除 ID 索引，再从 Items 中删除键值。别用简单循环+break，要处理多个同 ID 条目（虽然设计上不该有）。
- 推荐删除函数：
func (c *Cart) RemoveItem(id string) { for i, itemID := range c.Order { if itemID == id { c.Order = append(c.Order[:i], c.Order[i+1:]...) break } } delete(c.Items, id) } - 注意：切片删除后未重置
cap不影响功能，但若 cart 长期复用，可考虑make([]string, 0, len(c.Order))重建以释放内存
并发访问购物车怎么不出错？
HTTP handler 是并发执行的，多个请求同时操作同一个 *Cart 实例（比如用户快速连点加购）会导致 map panic：“concurrent map read and map write”。Go 的 map 默认非线程安全，必须加锁。
别用 sync.RWMutex 对整个 cart 加读写锁——写少读多才划算；购物车实际是读写均频，直接用 sync.Mutex 更稳妥。锁粒度也不必细化到每个 item，整个 cart 实例一把锁足够。
- 在
AddItem、RemoveItem、UpdateQuantity开头加：c.mu.Lock(); defer c.mu.Unlock() -
mu字段类型必须是sync.Mutex，不是*sync.Mutex（避免复制锁） - 避免在锁内做耗时操作：比如调用数据库或 HTTP 服务，应先取值、解锁、再处理
购物车看似简单，真正上线后最常出问题的不是逻辑，而是 ID 类型不一致、并发写 map、以及删除时切片和 map 不同步——这三处不盯紧，压测时大概率崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
