不能直接用 sort.slice，因为 sku 多维权重需动态组合排序、写死逻辑难维护且易因 nil 或类型不一致 panic；应定义 skusorter 接口、白名单校验 query 参数、浅拷贝切片、预展开字段提升性能。
SKU排序接口为什么不能直接用 sort.Slice？
因为商品 SKU 通常带多维权重（销量、价格、上架时间、库存状态），且排序规则常需动态组合（比如“销量优先，同销量按价格升序”），sort.Slice 写死逻辑难维护，也容易漏掉 nil 或类型不一致的字段导致 panic。
实操建议：
- 定义统一的
SkuSorter接口，让不同排序策略实现Less(i, j int) bool方法 - 在 Gin handler 中通过 query 参数（如
sort=hot_price）路由到对应策略，避免 if-else 堆砌 - 所有字段访问前加
if sku.X != nil判断，尤其price和sales常为指针类型
Gin 路由怎么接收并校验排序参数？
别用 c.DefaultQuery 直接 fallback，默认值会绕过校验，导致传错参数（比如 sort=abc）也悄悄走默认逻辑。
实操建议：
- 用
c.Query("sort")显式取值，配合白名单检查：if !slices.Contains(validSortKeys, sortKey) - 把排序字段映射封装成 map：
map[string]SkuSorter{"hot_price": &HotPriceSorter{}, "new_stock": &NewStockSorter{}} - 错误时统一返回
400 Bad Request和提示：{"error": "invalid sort parameter: abc"}
如何避免并发排序时 slice 被意外修改？
GIN handler 是复用的，如果把原始 SKU 列表直接传给 sort.Slice，多个请求可能同时操作同一底层数组，出现数据错乱或 panic。
实操建议：
- 每次请求都做浅拷贝：
skus := make([]*Sku, len(original)); copy(skus, original) - 禁止在排序函数里修改 SKU 字段（如
sku.Price = ...），只读比较 - 若需预处理（如补默认价格），在拷贝后、排序前一次性完成，不放在
Less里
性能瓶颈常卡在哪儿？
不是排序算法本身，而是字段解引用和空值判断——尤其当 SKU 有 1000+ 条、每条含 5~8 个可选字段时，Less 函数调用次数是 O(n log n)，每次都要做多次指针判空。
实操建议：
- 提前展开关键字段到临时结构体：
type sortableSku struct { id string; sales int; price float64; stockStatus bool } - 用
sort.SliceStable替代sort.Slice，保证相同权重时原始顺序不变（对“销量相同按上架时间”类需求很关键） - 缓存已解析的排序键（如
sku.Sales非空则用，否则用 0），但注意不要跨请求复用
sort.Slice 就完事。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
