递归函数结构化设计的核心是显式职责划分，包括明确递归契约、分离基例与递归逻辑、按数据流切分私有函数、用显式栈替代隐式调用。
递归函数要实现结构化设计，核心是把“隐式调用逻辑”变成“显式职责划分”。不是简单拆代码，而是围绕递归的天然结构——基例、子问题分解、结果组装——重新组织函数边界和协作关系。
明确递归契约，先定接口再写实现
结构化设计的第一步，是把递归函数当成一个有清晰输入输出承诺的“黑盒”。不急着写 body，先用自然语言写下它的功能定义，比如：
- “给定一棵树节点，返回其所有叶子节点的值列表”
- “给定字符串和索引，返回从该位置开始的最长回文子串”
这个描述直接决定参数设计（是否传 depth？是否带 accumulator？是否需要 context 对象？）和返回类型（void / boolean / object？）。接口一旦稳定，后续拆分、测试、替换才有依据。
分离基例与递归逻辑，各自独立成块
基例（base case）和递归体（recursive case）本质是两类控制流：一个是终止判断，一个是问题降维。强行混在同一函数里容易模糊边界，尤其当基例不止一种（如空节点、叶节点、超限深度）时。建议：
- 把所有基例判断提前集中处理，统一返回或抛出；
- 递归体只保留纯分解+组合逻辑，不掺杂条件分支；
- 必要时将基例封装为
isBaseCase(node)这样的判断函数，提升可读性与复用性。
按数据流切分私有函数，避免单函数承担多角色
一个超长递归函数往往同时做预处理、遍历、计算、后处理、错误转换。结构化重构的关键，是让每个私有函数只负责一条数据流环节：
- 输入适配器：把原始参数转成递归内部所需结构（如把 flat 数组转为树形 node + children）；
- 状态推进器：封装递归调用前的状态更新（如 depth++、path.push()、accumulator.merge()）；
- 结果合成器：把多个子调用结果合并（如数组 concat、数值累加、对象 merge）；
- 出口处理器：统一处理基例返回值（如 null → []、undefined → 0、Error → default value）。
这样即使递归主体变化，各环节也可单独测试或替换。
用显式栈替代隐式调用，把递归“摊平”为可控流程
当递归深度不可控或需中断/恢复/日志追踪时，结构化程度最高的做法是转为迭代+显式栈。这不是放弃递归思想，而是把“调用栈”从语言运行时移到代码中：
- 栈元素明确记录当前层级所需全部状态（node, depth, options, parentResult）；
- while 循环体成为唯一执行入口，逻辑线性、断点友好、易于插入监控；
- 原递归函数退化为初始化栈 + 启动循环的薄包装，职责单一且无副作用。
这种结构天然支持暂停、快进、回溯等高级能力，也便于 WorkBuddy 等工具自动插入性能探针或错误兜底逻辑。
