因为Gin HTTP处理同步阻塞，深度递归查询触发N次DB调用，易致连接耗尽、goroutine泄漏及超时；应改用一次查全量+内存构树方案。
为什么直接递归查数据库会卡死接口
因为 Gin 默认的 HTTP 处理是同步阻塞的，如果在 GET /categories 里写个深度递归查询（比如每层都 db.Where("parent_id = ?", id).Find(&children)），N 层嵌套就触发 N 次 DB 查询，还可能引发 goroutine 泄漏或 MySQL 连接耗尽。更糟的是，没加 context.WithTimeout 的话，前端等 30 秒超时，后端还在查第 5 层。
真正该做的是：一次查全量，内存构树。前提是分类总数可控（比如
- 用
SELECT * FROM categories ORDER BY parent_id, sort_order一次性拉出所有数据 - 遍历一遍，用
map[uint64]*Category缓存所有节点，再按parent_id指针挂载子节点 - 最后从
parent_id = 0或NULL的节点开始返回顶层
如何避免父子关系错乱导致空指针 panic
常见错误是没校验 parent_id 是否真实存在。比如某条记录 parent_id = 999，但数据库里根本没有 ID=999 的分类，此时若直接写 nodes[parentID].Children = append(...)，就会 panic：assignment to entry in nil map。
安全做法是：先建好所有节点的 map[id]*Category，再第二遍遍历做挂载。这样即使 parent_id 不存在，nodes[parentID] 是 nil，append 到 nil slice 不会 panic（Go 允许），只是不生效——这比崩掉强。
立即学习“go语言免费学习笔记（深入）”；
- 第一遍：for range 所有查出的记录，
nodes[item.ID] = &item - 第二遍：for range 同样数据，
if p := nodes[item.ParentID]; p != nil { p.Children = append(p.Children, nodes[item.ID]) } - 别忘了给每个
Category结构体预置Children []Category字段，不是*[]Category
Gin 返回 JSON 时怎么让前端拿到“扁平数组”还是“嵌套树”两种格式
运营后台要拖拽排序，得用扁平列表；商品页渲染导航栏，得用嵌套树。硬编码一种格式会逼前端自己 flatten 或 nest，效率低还容易出错。
最简方案是在 URL 加参数：/categories?format=tree 或 /categories?format=list，Gin 用 c.Query("format") 判断即可。注意别用 POST body 传，这种纯读操作必须用 GET。
-
format=tree→ 调用buildTree(nodes)，返回根节点及其递归子树 -
format=list→ 直接c.JSON(200, allCategories)，但需确保数据库查出来已按parent_id排序，方便前端用parentId字段自己组装 - 默认行为建议设为
tree，符合“多层级分类”的语义直觉
MySQL 中 parent_id 为 NULL 还是 0？字段类型怎么选
这个问题直接影响 Go 结构体定义和 SQL 查询条件。用 NULL 表示无父级，对应 MySQL 的 parent_id BIGINT UNSIGNED NULL，Go 里就得用 sql.NullInt64，否则 scan 时会报 sql: Scan error on column index 2: unsupported Scan, storing driver.Value type <nil> into type *uint64</nil>。
更省事的做法是统一用 0 表示根节点，MySQL 字段设为 parent_id BIGINT UNSIGNED NOT NULL DEFAULT 0，Go 结构体用 ParentID uint64，查询条件写 WHERE parent_id = 0，代码清爽且无空值陷阱。
- 如果历史库已用
NULL，别强行改表，用COALESCE(parent_id, 0)在 SQL 层兜底 - 千万别用
int类型存 ID，MySQL 的BIGINT对应 Go 的int64或uint64，越界会导致负数 ID - 前端传来的
parent_id创建新分类时，务必校验是否为合法存在的 ID（包括 0），防止伪造请求插入孤节点
实际跑通的关键不在 Gin，而在你敢不敢把“树形结构”这件事彻底交给内存处理。数据库只负责提供原子数据，构造关系是代码的事——只要分类总量不过万，这个思路稳得一批。
