必须显式创建带名称的 ForkJoinPool 实例，通过自定义 ForkJoinWorkerThread 子类和线程工厂设置线程名；DTO 字典装配应封装为 RecursiveTask，拆分阈值设为 50，字典查询须用专用 IO 线程池异步执行，CompletableFuture 各阶段必须显式指定线程池，严禁使用 commonPool。
不能靠默认的 ForkJoinPool.commonPool() 去干这件事。它共享、无名、不可控，一旦某个 DTO 装配触发慢 IO（比如没设超时的远程字典查询），整个 JVM 里所有用到 commonPool 的地方——并行流、CompletableFuture 默认执行、其他模块的 ForkJoin 任务——都会卡住或降速。
必须显式创建带名称的 ForkJoinPool 实例
给线程池命名，是可观测性和问题定位的第一步。ForkJoinPool 本身不直接支持构造时传 name，但可通过 ForkJoinWorkerThread 的子类实现：
- 自定义线程工厂，继承
ForkJoinWorkerThread.ForkJoinWorkerThreadFactory - 重写
newThread方法，在创建线程时设置有意义的名称，例如"dto-dict-assembly-worker-%d" - 将该工厂传入
ForkJoinPool构造器（需用public ForkJoinPool(int parallelism, ForkJoinWorkerThreadFactory factory, UncaughtExceptionHandler handler, boolean asyncMode)形式）
把 DTO 字典装配逻辑封装为 RecursiveTask
每个 DTO 实体可能有多个字典字段（如 statusName、deptName、categoryLabel），它们可独立查表或调用远程服务填充。这不是简单循环，而是典型的“可分治 + 可并行 + 需合并”场景：
- 继承
RecursiveTask（若只做装配无返回）或RecursiveTask（若需返回装配后 DTO） - 在
compute()中判断拆分阈值：若待装配 DTO 列表 size > 50，就 fork 出两个子任务；否则遍历列表，逐个调用字典服务填充属性 - 注意：字典查询必须是异步非阻塞的（如用 WebClient + Mono/Flux 或 CompletableFuture），否则会阻塞工作线程，破坏窃取机制
配合 CompletableFuture 实现 IO 与 CPU 工作解耦
ForkJoinPool 擅长 CPU 密集型分治，但字典装配常含远程调用。硬塞进 ForkJoinPool 容易拖垮线程。正确做法是分层调度：
- 用自定义 ForkJoinPool 处理“任务切分 + 结果聚合 + 属性赋值”这类 CPU 工作
- 字典查询本身交给专用的 IO 线程池（如
ThreadPoolExecutor配LinkedBlockingQueue和CallerRunsPolicy） - 在
RecursiveTask.compute()中，对每个 DTO 发起CompletableFuture.supplyAsync(() -> remoteDictService.get(...), ioPool) - 用
CompletableFuture.allOf(...).join()等待本批次所有查询完成（注意：这是阻塞等待，但发生在已 fork 出的子任务中，不影响其他线程窃取）
避免踩 commonPool 的坑，明确线程池归属
所有 CompletableFuture 的异步操作，只要涉及字典查询或后续加工，都必须显式传入线程池：
-
supplyAsync(..., ioPool)—— 查字典 -
thenApplyAsync(..., assemblyPool)—— 填充字段、转换格式（用你命名的 ForkJoinPool） - 绝不用
thenApplyAsync(...)无参形式，默认掉进commonPool() - CompletableFuture 的
join()或get()在 ForkJoinTask 内调用是安全的，但要确保上游已用对的池提交
