递归函数通用优化框架需分层应对：①重复计算用记忆化缓存层，支持对象键与lru管理；②栈溢出提供迭代回退通道，抽象状态为显式栈/队列；③调用效率靠尾递归契约加蹦床调度；④资源消耗通过参数解耦与稳定键设计控制。
为递归函数设计通用优化框架，关键不是堆砌技巧，而是按问题瓶颈分层干预：重复计算、栈深度、调用开销、内存占用这四类问题，各自对应一套可复用的解决机制。
针对重复子问题：统一接入记忆化缓存层
只要递归存在重叠子问题（如斐波那契、树形DP、路径计数），就应默认启用记忆化。不推荐手写 if (n in memo) 这类散落逻辑，而是封装成可插拔的缓存中间件：
- 参数为简单类型（数字/字符串）时，用轻量级对象字面量做缓存键：
{ [key]: result } - 参数含对象或嵌套结构时，改用
Map或WeakMap，避免隐式字符串转换导致键冲突 - 长期运行服务中，缓存需带生命周期管理——比如 LRU 驱逐策略，或按业务上下文自动清理（如一次请求结束后清空）
对抗栈溢出：提供迭代回退通道
所有递归函数都应预设“降级为迭代”的能力，尤其用于深度不确定的场景（如解析嵌套 JSON、遍历深层 DOM、处理用户自定义嵌套配置）。实现方式不是重写全部逻辑，而是：
- 将递归中的“当前状态 + 待处理子任务”抽象为数据结构（如数组栈或队列）
- 把原递归体拆成两部分：状态展开逻辑（push 子任务）、结果合并逻辑（pop 后处理）
- 保留统一入口，通过 flag 控制走递归分支还是迭代分支，便于灰度和压测
提升调用效率：强制尾递归契约 + 蹦床调度
尾递归本身不是银弹，但它是让递归具备可调度性的前提。设计时要求所有递归函数满足尾调用形式（即 return fn(...)，无后续运算），然后统一包裹蹦床：
- 尾递归函数只返回下一个调用函数，不执行它
- 蹦床函数接收该返回值，循环调用直到得到最终结果
- 这样既保持语义清晰，又规避了引擎未开启 TCO 的兼容性风险
控制资源消耗：缓存与参数解耦设计
记忆化常因序列化不当引发性能倒挂。例如对对象参数直接 JSON.stringify 作 key，会吃掉大量 CPU 且无法命中缓存。应分情况处理：
- 若参数是不可变简单值，直接用其作为缓存键
- 若含对象，提取关键标识字段（如
id、version）组合成稳定 key - 避免缓存大体积中间结果；必要时只缓存摘要（如哈希值或布尔判定结果）
