〇、问题背景任务书写得轻描淡写Notebook 表必须支持至少 3 级的父子级嵌套目录关系设计。听起来很简单但当我真正动手实现创建 / 查整棵树 / 改名 / 移动 / 删除5 个操作时发现这是整个后端目前最容易翻车的模块。我把这次踩到的 4 个核心问题挑出来讲每个都对应代码里一段真实的判断逻辑。一、第一个问题树到底怎么存主流方案三个方案写代价查整棵子树移动节点适合场景邻接表parent_idO(1)朴素写法要查 N 次O(1)写多读少、深度浅路径枚举path /1/3/7/O(h)LIKE 一条 SQL整棵子树 path 重写读多写少闭包表O(h)每个节点要插 h 行一条 JOIN多行增删查询极强、不怕写放大我选了邻接表 冗余 depth 字段。理由很现实我的深度被任务书锁死了 ≤ 3闭包表那种为查询无限优化的能力毫无收益用户会频繁重命名和移动目录闭包表写放大不划算MySQL 8 的递归 CTE 把邻接表查不动整棵树的传统痛点解决了邻接表的最大短板被补齐。但邻接表有个特别容易被忽略的小事parent_id是用 NULL 还是 0 表示根我选0。原因MySQL 索引对 NULL 的处理一向不友好WHERE parent_id ?在传 null 时还得改写成IS NULL业务代码全是分支。统一用 0 后所有 SQL 写法一致前端拿到parentId 0也立刻知道这是根节点——这是隐式契约但确实减少了大量心智负担。二、第二个问题查整棵树怎么避免 N1我第一版差点这么写NotebookTreeVO root ...;fillChildren(root); // 内部递归调 mapper.listChildren()void fillChildren(NotebookTreeVO node) {ListNotebook children mapper.listChildren(uid, node.getId());for (Notebook child : children) {NotebookTreeVO childVO toVO(child);node.getChildren().add(childVO);fillChildren(childVO); // 再递归}}看起来对。但每展开一个节点就跑一次 SQL深度 3、每层 5 个节点最坏会跑 1 5 25 31 次查询。这是经典的 N1 查询——单用户没事并发 50 用户同时打开工作台首页就是个事故现场。我换成一次 SQL 拉全量 O(n) 内存组装public ListNotebookTreeVO tree() {Long uid DataOwnershipAssert.currentUserIdOrThrow();ListNotebook all notebookMapper.listAllByUser(uid);// 1) 先建 id - VO 索引O(n)MapLong, NotebookTreeVO idIndex new HashMap(all.size() * 2);for (Notebook nb : all) {idIndex.put(nb.getId(), toTreeVO(nb));}// 2) 再走一遍按 parentId 挂到对应节点的 children 上O(n)ListNotebookTreeVO roots new ArrayList();for (Notebook nb : all) {NotebookTreeVO node idIndex.get(nb.getId());if (Objects.equals(nb.getParentId(), Notebook.ROOT_PARENT_ID)) {roots.add(node);continue;}NotebookTreeVO parent idIndex.get(nb.getParentId());if (parent ! null) {parent.getChildren().add(node);} else {roots.add(node); // 兜底理论上不应触发}}return roots;}1 次查询往返 O(n) 复杂度深度 100、节点 1000 的极端情况都在 50ms 以内。任务书要求响应 100ms轻松达标。这里有个细节我特意idIndex里建的是MapLong, NotebookTreeVO而不是MapLong, Notebook——这样第二遍循环挂 children 的时候挂的是已经准备好的 VO不用再做一次toVO转换。这可以在节点数大时省掉一半对象分配。三、第三个问题移动节点怎么避免成环这是我这周印象最深的一个 bug。用户操作把目录 A 拖到目录 P 下面正常情况没问题。但如果 P 本身就是 A 的子孙呢举个例子根 → 编程 → Java → Spring如果用户作死把编程拖到Spring下面数据会变成Spring → 编程 → Java → Spring ← 成环了后续findDescendantIds的递归 CTE 会无限展开直到 MySQL 切断整棵树的查询全部崩溃。我的拦截逻辑// 环检测新父节点不能在当前节点的子孙集合中if (newParentId ! Notebook.ROOT_PARENT_ID) {ListLong descendants notebookMapper.findDescendantIds(uid, id);if (descendants.contains(newParentId)) {throw new BadRequestException(不能把目录移动到它自己的子目录下);}}巧的是这正好复用了之前写的递归 CTEWITH RECURSIVE descendant AS (SELECT id, parent_id FROM notebook WHERE id #{rootId} AND user_id #{userId} ...UNION ALLSELECT n.id, n.parent_id FROM notebook n INNER JOIN descendant d ON n.parent_id d.id ...)SELECT id FROM descendant之前写它是为了级联软删没想到移动操作也直接受益。一段 SQL 撑两个完全不同的业务——这种复用感是我这周最爽的瞬间。四、第四个问题移动之后子树的 depth 怎么办这是我最后才意识到的坑。notebook表里我冗余存了depth字段方便 O(1) 校验不能超 3 级。但移动节点时子孙的 depth 也得跟着变——举例移动前根 (depth1) → 编程 (depth2) → Java (depth3)把编程移动到根级parent0单独执行move(编程, depth1)此时 Java 的 depth 还是 3但它现在的真实路径只有 2 级。数据不一致了。下次校验能不能在 Java 下面再建子目录时因为 Java.depth3校验逻辑会拒绝——而事实上根 (1) → 编程 (2) → Java (2但旧值是3) 还有空间。我加了一段shiftSubtreeDepthprivate void shiftSubtreeDepth(Long userId, Long rootId, int diff, LocalDateTime now) {if (diff 0) return;ListLong ids notebookMapper.findDescendantIds(userId, rootId);if (ids.size() 1) return;for (Long childId : ids) {if (Objects.equals(childId, rootId)) continue;Notebook child notebookMapper.findByIdAndUser(childId, userId);if (child null) continue;notebookMapper.move(childId, userId,child.getParentId(), child.getDepth() diff,child.getSort(), now);}}把整棵子树 depth 同步偏移diff 可以是正可以是负。反思冗余字段就像备份——一旦决定冗余就得保证所有变更入口都同步刷新它否则它就从性能助攻变成数据炸弹。我一开始没考虑到这一点是测试时手动跑了 3 次移动操作之后才发现 depth 飘了。这个教训我在后续做 Note 表时就提前规避了——所以 Note 不冗余 depth。五、补充还有一个隐藏坑——移动后会撑破 3 级吗移动节点 A 到新父 P 后A 的子孙最深叶能不能挺住 ≤ 3 级我加了一个子树相对深度的预判int newDepth resolveChildDepth(uid, newParentId); // A 移动后的新深度int subtreeDepth computeSubtreeMaxRelativeDepth(uid, id); // A 子树最深叶的相对偏移if (newDepth subtreeDepth Notebook.MAX_DEPTH) {throw new BadRequestException(移动后会超过最大层级 Notebook.MAX_DEPTH 级请先调整子目录结构);}逻辑是A 自己是 1叶节点最多比 A 深subtreeDepth层。把 A 挂到newDepth这个层级后叶节点的绝对层级 newDepth subtreeDepth不能超过 3。这一行校验帮我兜住了三种用户操作错误把已经 3 级的子树拖到非根目录下把 2 级目录连同 1 个孙子拖到 2 级位置把根目录的工作目录拖到孙级。六、收获写完目录树这块代码我对树形数据的认知刷新了数据库选模型这步必须想清楚——一旦动手就很难翻盘冗余字段是把双刃剑——给你性能也给你坑每个写入入口都得同步它环检测和深度校验不是可选项是用户作死操作时数据库的最后一道防线递归 CTE 不止用在删除——只要是找子孙这种问题它都是最优解。下一篇我会讲NoteUpdateDTO.tagIds这个字段的三态设计——一个看似平凡的字段背后是 PUT 接口语义、覆盖式更新、防御式校验三层考虑