直接递归查数据库会拖垮接口，因为几十到几百个分类节点若逐层查询将触发上百次SQL，迅速占满MySQL连接池并引发context deadline exceeded；正确做法是一次查全量分类数据，在内存中用map构建树形结构，再通过Gin的c.JSON返回。
为什么直接递归查数据库会拖垮接口
商品分类树常见几十到几百个节点，如果每个节点都查一次数据库，哪怕用 SELECT * FROM categories WHERE parent_id = ? 循环嵌套，10层深就可能触发上百次查询。Gin 本身不拦这个，但 MySQL 连接池很快被占满，context deadline exceeded 错误频发。
正确做法是一次性查出全部分类，再用内存构树。前提是：分类总数可控（一般不超过 5000 条）、层级不超 6 层（电商常见为 4 层以内）。
- 用
SELECT id, name, parent_id, sort_order FROM categories ORDER BY parent_id, sort_order拿全量数据，避免多次 round-trip - 用 map[int]*Category 做索引，O(1) 找父节点或子节点
- 注意
parent_id为 0 或 NULL 的节点才是根，别硬写成parent_id == 0而忽略 NULL 场景
Gin 路由里怎么返回带层级的 JSON 树
Gin 的 c.JSON() 不会自动处理循环引用或深层嵌套，你得自己构造树形结构体。别用嵌套 struct 递归定义（比如 Children []Category），Go 编译器不报错但序列化时容易栈溢出或漏字段。
推荐用扁平结构 + 一次性组装：
立即学习“go语言免费学习笔记（深入）”；
- 定义
type CategoryNode struct { ID int `json:"id"`; Name string `json:"name"`; Children []*CategoryNode `json:"children"` } - 先建所有节点的
map[int]*CategoryNode，再遍历原始数据，对每个节点找其parent_id对应的父节点，然后parent.Children = append(parent.Children, node) - 最后收集所有
parent_id == 0的节点作为 roots，传给c.JSON(200, roots)
前端传来的“移动分类”请求该怎么安全更新
用户拖拽调整分类顺序或修改隶属关系时，典型请求是 { "id": 105, "parent_id": 22, "sort_order": 3 }。这里最容易踩的坑是没做环路检测——比如把 A 的父节点设成 B，B 的父节点又设成 A，数据库存得进去，但后端构建树时直接死循环。
- 更新前先查出整条祖先链：
SELECT id, parent_id FROM categories WHERE id IN (..., ?, ...)，用递归或迭代向上追溯，发现重复 ID 就拒绝 -
sort_order别直接存整数，建议用 float64 或字符串（如 “10.5”），方便后续插入新分类时不用重排全部序号 - 更新用事务包裹，尤其涉及
UPDATE和可能的UPDATE children SET sort_order = sort_order + 1位移操作
要不要加缓存？Redis 存什么格式最省事
分类树变动频率低（运营后台改完才生效），但读 QPS 高，缓存非常值得。别存整个 JSON 字符串——每次改一个节点就要全量刷新；也别存每个节点单独 key——前端要一棵树得 N 次 GET。
推荐方案：用一个 key 存完整树的 JSON，过期时间设为 1 小时，后台改完立刻 DEL categories:tree。
- key 名用
categories:tree:v2，加版本号方便灰度或清旧数据 - 首次加载时从 DB 构建，成功后
SET categories:tree:v2 "{...}" EX 3600 - 注意 JSON 中时间字段别带
time.Time，用string或int64时间戳，避免 Gin 序列化时 panic
树结构越深、节点越多，内存组装和 JSON 序列化的开销越明显。上线前务必用 go tool pprof 抓一次真实请求的堆分配，确认没在树构建逻辑里产生大量小对象逃逸。
