python不支持尾递归优化，尾递归函数仍会栈溢出；必须手动转为迭代，用循环和状态变量替代递归调用，才能真正避免栈溢出。
Python 不支持尾递归优化（TCO），写成尾递归形式也不会节省栈空间 —— 这是硬限制，不是写法问题。
为什么 tail_recursive_sum(n, acc) 依然会栈溢出
你把 factorial 改成 fact_tail(n, acc)，或把求和写成 tail_recursive_sum(n, acc)，函数逻辑确实符合尾递归定义：return 后面只有函数调用，没有后续运算。但 CPython 解释器**完全忽略这个结构**，每次调用仍新建栈帧。运行 fact_tail(1000) 和 factorial(1000) 一样，大概率触发 RecursionError: maximum recursion depth exceeded。
这不是你漏写了什么参数，也不是没加 @lru_cache —— 是解释器根本没实现 TCO。Erlang、Scheme、Rust（部分模式）会做尾调用消除，Python 明确拒绝了这条路，理由是调试友好性和语义清晰性优先于栈空间优化。
真正有效的“尾递归思想”落地方式：手动转迭代
尾递归的本质，是把“下一层递归的状态”显式存为变量，然后用循环推进。这一步不能靠解释器，得人来写。
- 识别状态变量：比如
fact_tail(n, acc)中的n和acc就是全部状态 - 把 base case（如
n == 1）变成while循环条件 - 把递归调用体（
n-1,n * acc）变成循环内变量更新
例如：
def fact_iter(n):
acc = 1
while n > 1:
acc *= n
n -= 1
return acc
这段代码和 fact_tail 逻辑等价，但零栈帧增长、无深度限制、执行更快 —— 它才是你在 Python 里该写的“尾递归优化版”。
哪些递归适合这样转，哪些不该硬转
线性单路径递归（如阶乘、最大公约数、链表遍历、简单树深度）转迭代很自然；但以下情况强行转反而更糟：
- 二叉树中序遍历：需要模拟调用栈压入/弹出左右子树，代码比递归长一倍且易错
- 回溯类问题（如 N 皇后、全排列）：依赖递归的隐式回退机制，改成迭代需手动维护路径栈和状态标记，可读性暴跌
- 分治算法（如归并排序）：双递归分支天然匹配问题结构，硬拆成循环+显式栈会模糊核心逻辑
这时候优先考虑 @lru_cache 缓存重复子问题，或用 sys.setrecursionlimit()（仅限已知深度上限的场景，比如解析固定层级的 JSON 配置）。
别被“尾递归函数名”骗了
看到别人代码里有 def helper(..., acc=...) 并不意味着它被优化了。那只是把累积逻辑显式化，方便你后续改写为迭代，或为加缓存做准备。如果函数仍以递归方式调用自己，它就还是递归 —— 只不过结构更干净而已。
真正关键的判断点只有一个：函数体内有没有 return func(...) 这种调用？如果有，且没其他操作，那它是尾递归形式；但只要它还在调用自身，就仍在消耗栈空间。想省栈，必须消灭递归调用本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
