工作窃取需配合显式深度控制机制防止单次任务链过长；每个任务携带depth/maxDepth字段做硬剪枝，采用迭代式建模、逻辑层批量切分、环检测双标记及阻塞策略控流。
工作窃取（Work-Stealing）本身不直接限制遍历深度，但它能配合显式深度控制机制，在多级组织架构图的异步深挖中有效防止单次任务链过长、线程栈溢出或物理线程数失控。关键不是靠线程池“自动限深”，而是把深度约束嵌入任务单元设计，并让 WorkStealingPool 在任务粒度可控的前提下高效调度。
用 depth 字段做硬性剪枝，而非依赖递归调用栈
组织架构常达 15+ 层，纯递归 DFS 易爆栈；而 WorkStealingPool 虽基于 ForkJoinPool，但若任务封装仍用递归 fork()，深度失控会迅速耗尽线程资源。必须改用迭代式任务建模：
- 每个任务对象（如
OrgScanTask）携带depth和maxDepth字段，进入前先校验：if (depth >= maxDepth) return; - 子任务由当前任务显式生成并 fork，不递归调用自身 —— 避免闭包堆栈累积
- 根任务设
maxDepth = 5（例如只挖到“部门→科室→小组”三级），超出即终止该分支，记录 warn 日志而非抛异常
任务拆分粒度匹配深度目标，避免“一节点一任务”的陷阱
不是每个组织节点都扔进队列；否则百万节点 → 百万任务 → 线程池虚假饱和（大量空转/上下文切换）。应按“逻辑层+批量”切分：
- 第一层：根部门列表（如 10 个大区）→ 拆成 10 个顶层任务，
depth=0 - 第二层：每个大区下查出全部直属二级部门（如每区平均 20 个）→ 合并为 1 个子任务，
depth=1，内部循环处理 - 第三层起：仅对满足业务条件的节点（如
type == "team" && status == ACTIVE）才触发下探，且批量拉取（如一次 fetchChildren(idList, limit=100)）
用 ForkJoinPool.ManagedBlocker 或自定义阻塞策略控流
WorkStealingPool 默认不感知业务深度，但可通过阻塞感知间接抑制过度并发：
- 在任务执行前，检查全局当前最大活跃深度（用
AtomicInteger统计），超阈值（如 >4）则调用ForkJoinPool.managedBlock()让当前线程临时让出窃取资格 - 或在任务提交前加轻量级令牌桶：
if (!depthLimiter.tryAcquire()) { fallbackToSyncScan(node); return; } - 避免使用 synchronized 或锁——会破坏窃取效率；优先选无锁计数 + 快速失败
结合 visited + pathSet 做环剪枝，防止深度误增
矩阵汇报、虚线管理等导致逻辑环，若不检测，pathSet 不断增长 → 表面 depth 不高，实际调用链爆炸。必须双标记：
-
visited[nodeId]：全局去重，防重复加载同一节点 -
pathSet：当前任务路径上的节点 ID 集合（ThreadLocal 存储），每次 fork 子任务时传入副本 - 子节点加入前先 check：
if (pathSet.contains(childId)) { log.warn("Cycle detected at {} → {}", nodeId, childId); return; }，立即终止该分支
深度控制不是加个参数就能生效，它得落在任务创建逻辑里、卡在数据加载前、融在环检测中。WorkStealingPool 提供的是弹性调度底座，真正管住“挖多深”的，是你封装的每个 compute() 方法里的那几行判断。
