一、问题找上门了

上周我们公司的线上点餐服务快被用户催炸了——高峰期每10分钟就崩一次，运营同学每隔5分钟就发一条“快点修好，用户等不及下单！”的消息，开发团队紧急召开了火线排查会。一开始大家以为是第三方支付接口超时，或是数据库锁表的问题，查了一下午日志才发现：每次崩溃的错误信息里都标着“栈溢出”，通俗来说就是“我们给函数调用准备的那张小桌子，被一层叠一层的调用给堆满了，新的东西放不进去，直接掉地上了，程序就崩了”。

1.1 诡异的本地vs线上差异

本地测试的时候，我们用的都是小数据量：每个用户最多给10张优惠券，计算优惠的时候用递归遍历，从来没出过问题。但线上高峰期，一个用户就能领1500张优惠券，递归调用的层数直接冲破了系统给的“桌子容量”，导致崩溃。这里我先放一段出问题的代码，技术栈统一用大家熟悉的Python 3.10，方便理解：

# 技术栈：Python 3.10
# 存在栈溢出风险的递归计算函数
def calculate_discount_recursive(remaining_coupons, current_total=0):
    # 错误的递归逻辑：终止条件写反了？不，是递归深度随数据量变大
    if remaining_coupons:
        # 取第一笔优惠券金额累加
        current_total += remaining_coupons.pop(0)["value"]
        # 递归调用：把剩下的优惠券列表传进去，导致层数随优惠券数量增加
        return calculate_discount_recursive(remaining_coupons, current_total)
    return current_total

# 调用示例：本地测用10张，线上高峰期会出现1500张的情况
user_coupons = [{"value": 1}] * 1500  # 线上常见的大数量场景
calculate_discount_recursive(user_coupons)  # 这里会直接抛出RecursionError栈溢出

二、火线定位全流程

2.1 先抓栈溢出的“实锤”

我们首先用线上服务的崩溃日志（core dump文件）分析，把栈的调用链一层一层打出来，发现所有崩溃的栈帧都是上面那个递归函数。Python里有个简单的工具可以看递归深度上限，线上默认的递归深度是1000层，1500层的调用肯定会超过这个上限，栈直接被撑爆。这段查看递归深度的代码很实用，大家本地调试也可以用：

# 技术栈：Python 3.10
import sys
print("当前允许的最大递归层数：", sys.getrecursionlimit())  # 输出默认1000左右

2.2 定位的关键细节

后来我们复盘时发现，大家写这个递归函数的时候，只考虑了逻辑正确，完全没考虑线上的极端数据量——本地测试最多用10张优惠券，递归只有10层，离1000层的上限差得远，根本测不出问题。线上的真实用户行为是，经常有用户同时领多个新人券、满减券，累计下来动辄上千张，这就是问题的根本原因。

三、快速修复方案

3.1 从递归改到迭代，彻底解决栈溢出

递归是“一层层剥洋葱，每剥一层都要记住上一层的位置”，而迭代是“像数数字一样，一个个往下走，不用记之前的内容”，后者不会占用额外的调用栈空间，自然不会栈溢出。我们把刚才的递归函数改成迭代版本，代码如下：

# 技术栈：Python 3.10
# 修复后的迭代版本，完全避免栈溢出
def calculate_discount_iterative(user_coupons):
    total = 0
    # 用for循环遍历所有优惠券，不用递归，不管多少张都不会有栈问题
    for coupon in user_coupons:
        total += coupon["value"]
    return total

# 测试1500张优惠券，完全正常
user_coupons = [{"value": 1}] * 1500
result = calculate_discount_iterative(user_coupons)
print(f"总优惠金额：{result}")  # 输出1500，正常

3.2 再加一层防御机制

为了避免以后再出现类似问题，我们还加了一个规则：每个用户最多只能领取50张优惠券，从根源上限制需要处理的数据量。哪怕哪天不小心用了递归，50层的调用也远低于系统允许的上限，不会崩溃。这个小规则是线上服务稳定性的最后一道防线，非常实用。

四、相关技术的补充说明

4.1 栈溢出的原理（生活化解读）

你可以把调用栈想象成一张给函数用的小桌子，每个函数调用就是往桌上放一个盘子，递归调用就是一直往桌上堆盘子，堆到桌子放不下的时候，再放盘子就会掉下来，这就是栈溢出。不同语言的默认栈深度不一样，比如Python默认1000层，Java默认10000层左右，但大数据量下都会撑爆。

4.2 递归vs迭代的优缺点

递归的优点是代码简洁，逻辑清晰，比如处理树形结构、层级数据的时候，递归写起来很轻松；缺点是递归深度受限制，大数据量下很容易栈溢出，而且还会额外占用栈空间，性能比迭代稍差。迭代的优点是稳定，没有栈溢出风险，适合大数据量的场景，性能更好；缺点是代码相对繁琐，需要手动写循环逻辑。

五、应用场景、注意事项总结

5.1 典型应用场景

这种递归/遍历的逻辑，在电商、点餐、内容社区这类服务里太常见了：比如计算优惠券总金额、遍历用户的收藏夹、处理文章的多级评论，这些场景都要注意数据量的问题，不能随便用递归。

5.2 开发注意事项

第一，写递归的时候一定要设终止条件，并且确保能到达终止条件，比如刚才的递归函数如果没写if remaining_coupons，会一直递归到列表为空（虽然这里是对的，但如果逻辑写错就会无限递归）；第二，一定要做压力测试，线上的用户数据和本地测试的小数据完全不一样，必须用线上能达到的最大数据量测；第三，对于不确定数据量的逻辑，优先用迭代，不要图省事用递归。

5.3 技术优缺点总结

递归：优点是代码短、易读，适合小数据量；缺点是栈溢出、受深度限制，不适合大数据量。迭代：优点是稳定、无栈溢出风险，适合大数据量；缺点是代码稍长，需要手动管理循环逻辑。

六、本次修复的心得

这次从发现崩溃到修复完成只用了1小时，核心原因是我们快速定位到了栈溢出的问题，并且用迭代的方式彻底解决。后来我们给团队做了一次分享，强调了“线上测试要覆盖极端数据”“递归必须考虑深度”这两个点，避免其他服务再出现类似问题。线上服务的稳定不是靠运气，而是靠每一次代码都考虑到可能的极端场景，以及遇到问题时快速定位和修复的能力。