组织节点过滤与子项查询：从非0处理到树形递归的完整实践

1. 先把“0节点”的来龙去脉搞清楚：它为什么会混进来

组织架构类的功能，无论是做权限控制、数据隔离，还是做部门树展示，基本都逃不开“按组织节点筛选数据”这个动作。我接手过好几个类似需求，最典型的一个是：调用方从前端传过来一批部门ID，后端拿着这批ID去查这些部门下所有人员的数据，再往下钻取到子部门。

任务看起来不复杂，但第一眼看到原始需求描述——“根据传入的组织节点，取出非0节点，为了后续SQL中查询其子项”——我就知道这里头有几个坑得提前踩平。

1.1 组织节点ID里的0，通常是什么来历

0出现在组织节点ID里，不是偶发情况。结合我见过的几个真实项目，0的“出身”基本有三种：

• 数据库里的默认占位值。很多表设计时，如果某个节点没有上级，上级字段就存0；或者某些环节还没分配真实组织，落库时临时用0兜底。
• 前端传参的占位ID。前端在构建筛选条件时，可能用0代表“不限组织”“全部部门”，或者树组件未选中任何节点时默认给0。
• 树形结构根节点的特殊约定。有些系统约定用0作为虚拟根节点，它不是真实存在的组织，但会在遍历时被带出来。

这三种情况都会导致一个问题：传入的组织节点集合不“干净”。如果不做处理，0就会跟着真实ID一起进入后续SQL，查出来的子项数据就会被污染。

1.2 让0进入SQL之后，会发生什么

这里我专门踩过一次。当时是给某审批系统做部门数据权限过滤，同事写的代码是直接拿传入的List去拼SQL的IN条件：

WHERE org_id IN (1243, 0, 441, 0)

表面上看，多一个0好像无关痛痒——数据库里根本没有org_id=0的记录，查出来结果集不受影响。

但问题恰恰出现在“子项查询”这个环节。你要知道，这里拿0去查的是“子项”，也就是说SQL不是查org_id=0本身，而是查org_id=0的下级节点。

如果0被定义为虚拟根节点，那它的下级是谁？可能是所有顶级部门。于是这条SQL的真实含义就变成了“取出所有顶级组织及其子项”，数据权限筛选瞬间被绕过，整个部门树的数据全部暴露出来。

还有一种情况是0被定义成“无归属”节点的父ID，那么查它的子项时会捞出来一堆脏数据，这些数据在组织树上根本找不到位置，却出现在业务查询结果里。

所以，“取出非0节点”不是一个代码洁癖问题，而是一个数据安全和语义正确性问题。这也是为什么它在需求里被单独拎出来强调。

1.3 需求的真实边界：不是去掉0就完事

把这句话拆开看，其实包含两层含义：

1. 过滤层：从传入集合中去掉非法的0节点（顺带还要处理null、空串这类异常值）。
2. 追溯层：拿着过滤后的节点集合，去查询这些节点的子项节点，再把子项节点作为最终的数据范围。

很多人写完第一层就交差了，结果在第二层翻车——因为**“查询其子项”本身就是一个需要单独设计的树形递归问题**。

2. 取出非0节点的写法：从最朴素的方法到实用工具类

过滤0这件事本身不难，难的是把它写得健壮、可复用、不埋雷。我见过各种写法，这里把从简到繁的几个版本都列出来，并说明每个版本适合什么情况。

2.1 第一个版本：兼容老项目的for循环写法

如果项目还在用JDK 7或更早版本，或者团队风格比较传统，直接用基础循环最稳：

public static List<Integer> filterNonZeroNodes(List<Integer> orgIds) { if (orgIds == null) { return new ArrayList<>(); } List<Integer> result = new ArrayList<>(); for (Integer orgId : orgIds) { if (orgId != null && orgId != 0) { result.add(orgId); } } return result; }

这个版本逻辑一眼就能看懂：null和0都排除。当然要注意的是，orgId != 0这里其实有自动拆箱，如果集合里有null元素，走到这一步之前先被orgId != null拦住了，所以不会抛NullPointerException。

2.2 使用Stream的推荐写法

如果项目是JDK 8及以上，我用Stream写会更简洁，也更容易在链式操作里追加其他过滤条件：

public static List<Integer> filterNonZeroNodes(List<Integer> orgIds) { if (orgIds == null || orgIds.isEmpty()) { return new ArrayList<>(); } return orgIds.stream() .filter(Objects::nonNull) .filter(orgId -> !orgId.equals(0)) .distinct() .collect(Collectors.toList()); }

注意两点：

• distinct()是我主动加的。同一个组织ID在传入集合里重复出现很常见，尤其是前端树组件多选时，父节点和子节点可能同时被勾选。去重一方面让后续SQL的IN条件更短，另一方面避免递归CTE里出现重复路径导致结果集异常。
• 用!orgId.equals(0)而不是orgId != 0。原因很简单：避免自动拆箱的隐患，也让代码风格统一。虽然前面filter已经排掉null，但团队里如果有人抽走那段非空判断，拆箱NPE就回来了。

2.3 泛型化和策略化设计

实际项目里组织ID不全是Integer，很多系统用的是Long或者String。所以工具类最好是泛型化：

public static <T> List<T> filterNonZero(Collection<T> source, Predicate<T> invalidPredicate) { if (source == null || source.isEmpty()) { return new ArrayList<>(); } return source.stream() .filter(Objects::nonNull) .filter(invalidPredicate.negate()) .distinct() .collect(Collectors.toList()); }

调用时传入对应的判定条件：

// Integer场景 List<Integer> validIds = OrgNodeUtils.filterNonZero( inputIds, id -> id.equals(0)); // Long场景 List<Long> validLongIds = OrgNodeUtils.filterNonZero( inputIds, id -> id.equals(0L));

这里我把“什么算非法”抽象成了Predicate，好处是后续如果新增规则，比如“负数也过滤”“空串也过滤”，不需要改工具类本身，调用方传不同Predicate即可。这是我在代码评审阶段被反复要求调整后沉淀下来的方案，一开始直接写死“只过滤0”，后来发现不同接口对“非法节点”的定义并不完全一致。

2.4 随手写几个单元测试，防止被人乱改

这类工具方法我强烈建议配单元测试，因为逻辑太简单，反而容易被后续维护的人“优化”出问题：

@Test void shouldFilterZeroAndNull() { List<Integer> input = Arrays.asList(0, 12, null, 0, 35, 98); List<Integer> result = OrgNodeUtils.filterNonZero(input); assertEquals(Arrays.asList(12, 35, 98), result); } @Test void shouldReturnEmptyListWhenAllZero() { List<Integer> input = Arrays.asList(0, 0, 0); assertTrue(OrgNodeUtils.filterNonZero(input).isEmpty()); } @Test void shouldHandleNullInput() { assertTrue(OrgNodeUtils.filterNonZero(null).isEmpty()); } @Test void shouldDistinctDuplicatedIds() { List<Integer> input = Arrays.asList(88, 88, 12, 12, 0); List<Integer> result = OrgNodeUtils.filterNonZero(input); assertEquals(Arrays.asList(88, 12), result); }

这些用例覆盖了四个最容易翻车的场景：混合数据、全非法数据、空输入、重复数据。项目组里后来有人把distinct删了，就是靠第二个用例相关场景的回归测试发现的，所以测试看着不起眼，关键时刻很救命。

3. 拿到非0节点之后：查询子项的正确姿势

标题里后半句“为了后续SQL中查询其子项”，我认为是整个需求真正的难点。很多人在这一步仍然用最原始的WHERE org_id IN (...)去查，这在语义上是错的。

3.1 为什么不能直接用IN查询子项

假设过滤后得到的节点是[12, 35]，你的意图是查询“node 12的子节点、node 35的子节点”。但WHERE org_id IN (12, 35)查到的是什么？是org_id本身等于12或35的记录。

• 如果数据表设计是把“父节点ID”存在每条记录上，那你应该查WHERE parent_id IN (12, 35)。
• 如果数据结构是闭包表、邻接表或多级路径，那你需要的是一棵子树，而不是简单的一层子节点。

这两种情况都绕不开“递归”二字。组织架构的层级通常不止一层，比如总公司→事业部→部门→小组，你要查的“子项”到底是指直接下级，还是整棵子树？绝大多数业务场景要求的是整棵子树。

3.2 方案一：MySQL 8的WITH RECURSIVE递归CTE

如果你的数据库是MySQL 8.0及以上，PostgreSQL、SQL Server或Oracle，直接用递归CTE最省事：

WITH RECURSIVE org_subtree AS ( -- 锚点：传入的根节点 SELECT org_id, org_name, parent_id, 1 AS level FROM sys_org WHERE org_id IN (12, 35) UNION ALL -- 递归：查每个节点的直接子级 SELECT child.org_id, child.org_name, child.parent_id, ot.level + 1 FROM sys_org child INNER JOIN org_subtree ot ON child.parent_id = ot.org_id ) SELECT org_id, org_name, parent_id, level FROM org_subtree;

这个SQL的优点：

• 一次查询拿到整棵子树，不依赖Java层多次查询。
• 天然去重，UNION的语义保证了节点不会重复出现。
• 层级字段level方便后续做缩进、权限深度控制等逻辑。

Java端调用时需要把过滤后的节点list传进去。以MyBatis为例，需要特别注意一个细节——如果传一个空list进来，IN条件会生成IN ()，直接SQL语法报错。所以调用前的判空处理是必不可少的：

public List<OrgNode> querySubTree(List<Integer> rootIds) { if (rootIds == null || rootIds.isEmpty()) { return new ArrayList<>(); } return orgMapper.selectSubTree(rootIds); }

Mapper里的写法：

<select id="selectSubTree" resultType="OrgNode"> WITH RECURSIVE org_subtree AS ( SELECT org_id, org_name, parent_id, 1 AS level FROM sys_org WHERE org_id IN <foreach collection="orgIds" item="orgId" open="(" separator="," close=")"> #{orgId} </foreach> UNION ALL SELECT child.org_id, child.org_name, child.parent_id, ot.level + 1 FROM sys_org child INNER JOIN org_subtree ot ON child.parent_id = ot.org_id ) SELECT org_id, org_name, parent_id, level FROM org_subtree </select>

3.3 方案二：Java层递归收集后代节点ID

如果你的项目还在MySQL 5.7或更早版本——这在实际存量系统里很常见——CTE语法用不了。这种情况下我推荐Java层递归组装后代ID集合，配合Batch IN查询。

先写一个简单的节点对象：

public class OrgNode { private Integer orgId; private Integer parentId; private String orgName; // getter / setter 省略 }

递归收集后代节点ID：

public static Set<Integer> collectDescendantIds(List<OrgNode> allNodes, Collection<Integer> rootIds) { Set<Integer> result = new HashSet<>(rootIds); // 建立父ID -> 子节点列表的映射 Map<Integer, List<OrgNode>> childrenMap = allNodes.stream() .filter(node -> node.getParentId() != null) .collect(Collectors.groupingBy(OrgNode::getParentId)); // 广度优先遍历 Deque<Integer> queue = new ArrayDeque<>(rootIds); while (!queue.isEmpty()) { Integer currentParentId = queue.poll(); List<OrgNode> children = childrenMap.getOrDefault(currentParentId, Collections.emptyList()); for (OrgNode child : children) { if (result.add(child.getOrgId())) { queue.offer(child.getOrgId()); } } } return result; }

这个写法的核心逻辑：

• 先加载全量组织节点，一次性在内存里建好父子映射。
• 用队列做广度优先遍历，每到一个节点就找出它的直接子节点，加入结果集并继续入队。
• result.add的返回值天然去重，防止父子环结构导致死循环。

组织表本身数据量通常不大，几千个节点全量加载内存压力可以忽略。比起每层递归查一次数据库，这种改法把数据库交互压缩到两次：一次查全量组织、一次按结果集查业务数据，性能反而更好。

3.4 两个方案到底怎么选

我的建议是：能用CTE就用CTE，毕竟SQL层做树形递归是数据库设计好的功能，写起来最简单、出错概率最低。老库没法用CTE时再考虑Java层方案。另外还有一种场景推荐Java层方案——如果目标是“查子项ID去查其他系统的接口”，那在Java层把ID集合算好反而更灵活。

4. 实战中极易翻车的四个细节

过滤节点和查子项的框架搭好之后，剩下的就是细节。以下四个坑是我在实际项目中一个个趟过来的，每一条都对应过一次线上问题或代码评审的返工。

4.1 空集合问题：永远不要拼出“IN ()”

这是最经典的坑。过滤后如果全部节点都是0，得到的集合是空的。这时候如果直接拿空集合去拼SQL：

WHERE parent_id IN ()

MySQL直接语法报错。

我的处理方案是三层防御：

• 工具层：过滤方法返回空集合而不是null，让调用方不用做双重判断。
• Service层：发现空集合就提前return，不再发起数据库调用。
• SQL层：MyBatis里用<if test="orgIds != null and orgIds.size() > 0">包住IN条件，即便前面漏了判空，SQL也不会炸。

单据层做法：

List<Integer> validRootIds = OrgNodeUtils.filterNonZero(orgIds); if (validRootIds.isEmpty()) { // 返回空结果，或者按业务约定查“未分配组织”的节点 return Collections.emptyList(); }

4.2 IN条件的长度上限：超过1000怎么办

MySQL和Oracle对单个IN条件的元素数量都不是无限支持。MySQL本身没硬性限制，但过长的IN会导致索引选择变差、性能下降；Oracle则明确有1000个上限。

当组织规模大，或者递归收集后代ID之后数量巨大时，必须分批处理。我常用的思路是按固定大小拆组，多次查询后合并结果：

public <T> List<List<T>> partition(Collection<T> ids, int size) { List<T> list = new ArrayList<>(ids); List<List<T>> partitions = new ArrayList<>(); for (int i = 0; i < list.size(); i += size) { partitions.add(list.subList(i, Math.min(i + size, list.size()))); } return partitions; }

然后循环查询：

List<BusinessData> finalData = new ArrayList<>(); for (List<Integer> batch : partition(validIds, 500)) { finalData.addAll(businessMapper.selectByOrgIds(batch)); }

批量大小我一般取500，兼顾SQL性能和数据库连接往返次数。实际测试里，500一批和1000一批性能差距不大，但500能给后续扩展Oracle兼容留出安全余量。

4.3 防注入：参数占位符终究是底线

我见到过有人图方便，把节点ID集合直接toString拼进SQL字符串：

// 反例，绝对不要这么干 String sql = "SELECT * FROM biz_data WHERE org_id IN (" + ids + ")";

一旦传进来的ID是"1) OR 1=1 --"这种字符串，SQL注入就发生了。虽然组织ID是整数，但谁能保证调用方不传怪东西过来呢？

正确做法是MyBatis的#{}参数占位符配合foreach：

<foreach collection="orgIds" item="orgId" open="(" separator="," close=")"> #{orgId} </foreach>

#{}会走PreparedStatement的参数绑定，由数据库驱动处理转义，注入风险为零。这个底线不能破，哪怕团队里有老手图省事想直接拼串，我也建议评审阶段把它拦下来。

4.4 “只过滤0”还是“过滤所有无效值”：策略化处理更从容

需求说的是“取出非0节点”，但实际上除了0，还会碰到null、负数、空字符串（如果是String类型的ID）。我在某数据平台项目里遇到过一种情况：传入节点ID里有-1，业务含义是“未分配任何组织”，跟0一样需要过滤。

所以我不建议工具方法里写死“非0”，而是把判断策略留在调用方。还是用前面提到的Predicate方案：

// 0 和 -1 都视为无效节点 Predicate<Integer> invalidOrgId = id -> id == null || id == 0 || id == -1; List<Integer> validIds = OrgNodeUtils.filterNonZero(inputIds, invalidOrgId);

这样每个服务可以根据自己的业务约定决定哪些ID是“无效节点”，而不是被一个通用工具方法绑死。当然，对于题目本身的场景——只要求非0——直接用默认实现即可，不需要过度设计。

5. 完整示例：从工具类到Service再到SQL的一条龙

把前面的内容串起来，我给出一个可直接参考的完整实现，包含工具类、Service层和Mapper层，大家可以根据自己项目按需裁剪。

5.1 完整的工具类代码

public final class OrgNodeUtils { private OrgNodeUtils() { } /** * 过滤集合中的 null 和 0，并去重。 * 返回值保证不为 null；若入参为空或过滤后无有效节点，返回空集合。 */ public static List<Integer> filterNonZero(List<Integer> orgIds) { if (orgIds == null || orgIds.isEmpty()) { return new ArrayList<>(); } return orgIds.stream() .filter(Objects::nonNull) .filter(id -> id != 0) .distinct() .collect(Collectors.toList()); } /** * 通用的非法节点过滤方法，调用方自定义“非法节点”的判断逻辑。 */ public static <T> List<T> filterInvalidNodes(Collection<T> source, Predicate<T> invalidPredicate) { if (source == null || source.isEmpty()) { return new ArrayList<>(); } return source.stream() .filter(Objects::nonNull) .filter(invalidPredicate.negate()) .distinct() .collect(Collectors.toList()); } /** * 全量组织节点 + 根节点集合，递归收集所有后代节点ID。 */ public static Set<Integer> collectDescendantIds(List<OrgNode> allNodes, Collection<Integer> rootIds) { Set<Integer> result = new HashSet<>(rootIds); Map<Integer, List<OrgNode>> childrenMap = allNodes.stream() .filter(node -> node.getParentId() != null) .collect(Collectors.groupingBy(OrgNode::getParentId)); Deque<Integer> queue = new ArrayDeque<>(rootIds); while (!queue.isEmpty()) { Integer currentParentId = queue.poll(); List<OrgNode> children = childrenMap.getOrDefault(currentParentId, Collections.emptyList()); for (OrgNode child : children) { if (result.add(child.getOrgId())) { queue.offer(child.getOrgId()); } } } return result; } }

Service层调用示例：

@Service public class OrgQueryServiceImpl implements OrgQueryService { private final OrgMapper orgMapper; private final BusinessDataMapper businessDataMapper; public OrgQueryServiceImpl(OrgMapper orgMapper, BusinessDataMapper businessDataMapper) { this.orgMapper = orgMapper; this.businessDataMapper = businessDataMapper; } @Override public List<BusinessData> queryDataByOrgIds(List<Integer> inputOrgIds) { // 第一步：过滤非法节点（0、null、重复） List<Integer> validRootIds = OrgNodeUtils.filterNonZero(inputOrgIds); if (validRootIds.isEmpty()) { return Collections.emptyList(); } // 第二步：查询所有子项节点 List<OrgNode> allOrgNodes = orgMapper.selectAllOrgNodes(); Set<Integer> descendantIds = OrgNodeUtils.collectDescendantIds( allOrgNodes, validRootIds); // 第三步：分批查询业务数据（防止IN过长） List<BusinessData> result = new ArrayList<>(); for (List<Integer> batch : partition(new ArrayList<>(descendantIds), 500)) { result.addAll(businessDataMapper.selectByOrgIds(batch)); } return result; } private List<List<Integer>> partition(List<Integer> ids, int size) { List<List<Integer>> partitions = new ArrayList<>(); for (int i = 0; i < ids.size(); i += size) { partitions.add(ids.subList(i, Math.min(i + size, ids.size()))); } return partitions; } }

如果是MySQL 8环境，第二步可以换成3.2里那条递归CTE，整体链路更短。

5.2 更进一步：把组织树数据做缓存

组织架构本身变动频率低，如果每次查询都全量加载组织节点，在高频接口里有点浪费。我后来在项目里做了一层简单缓存：用定时任务每5分钟刷新一次组织表，加载到内存里的Map<Integer, List<OrgNode>>结构，同时保留一个version字段做缓存失效标记。

@Component public class OrgTreeCache { private volatile Map<Integer, List<OrgNode>> childrenMap = Collections.emptyMap(); private final OrgMapper orgMapper; public OrgTreeCache(OrgMapper orgMapper) { this.orgMapper = orgMapper; } @Scheduled(fixedDelay = 300000) public void refresh() { List<OrgNode> allNodes = orgMapper.selectAllOrgNodes(); Map<Integer, List<OrgNode>> newMap = allNodes.stream() .filter(node -> node.getParentId() != null) .collect(Collectors.groupingBy(OrgNode::getParentId)); this.childrenMap = newMap; } public Set<Integer> collectDescendants(Collection<Integer> rootIds) { Set<Integer> result = new HashSet<>(rootIds); Deque<Integer> queue = new ArrayDeque<>(rootIds); while (!queue.isEmpty()) { Integer pid = queue.poll(); for (OrgNode child : childrenMap.getOrDefault(pid, Collections.emptyList())) { if (result.add(child.getOrgId())) { queue.offer(child.getOrgId()); } } } return result; } }

注意childrenMap用了volatile，保证多线程下能看到最新引用。刷新时整个Map替换，不用加锁，读操作无锁访问，性能很好。这套方案在数据量几千节点、QPS几百的场景下跑了大半年，没出过问题。

5.3 关于数据权限的扩展思考

拿到子项ID之后，通常还要叠加登录用户的权限过滤。比如用户只能看自己管辖范围内的组织数据，这时候光靠“非0过滤”不够，还得在Service层把“传入节点集合”和“用户权限节点集合”做一个交集：

Set<Integer> permissionOrgIds = getPermissionOrgIds(userId); Set<Integer> targetOrgIds = descendantIds.stream() .filter(permissionOrgIds::contains) .collect(Collectors.toSet());

这一步我习惯放在子项查询之后而不是之前，因为用户传入的可能是根节点，权限节点也可能是根节点，只对根节点求交集会漏掉深层子项的权限控制。先展开子树再过滤，逻辑上更严密。

写在最后的一个小建议

这类“取出非0节点”的工具方法，看起来三五行代码就能写完，但真正放到生产环境里，考验的是对业务语义的理解和对边界情况的处理。0不是你随便踢掉就完事的，你得知道它为什么存在、踢掉之后数据流的下一站在哪、SQL层会发生什么。

我个人的习惯是：凡是涉及组织节点、用户ID这类集合传参的方法，一律先做三层防护——判空、去重、过滤非法值，然后在Service层再兜底一次空集合提前返回。这种“笨功夫”多花不了几分钟，却能让接口在各种异常调用下都保持稳定。

如果各位在自己项目里也碰到组织树查询、子项展开、权限过滤这类需求，可以把本文的代码拿去改改。遇到具体场景拿不准的，多和业务方确认一下“子项”的定义到底是直接下级还是全量子树、0的语义到底是什么，这两件事问清楚了，代码怎么写都不会跑偏。