Python的异常处理把我搞怕了，原来try放在循环内外差别这么大

讲个真事儿。

去年我们做了一个数据迁移工具，要从旧系统导入10万条用户记录。每条记录有几十个字段，来源是CSV文件。我写了一段看起来很健壮的代码：

for row in csv_reader:
    try:
        user = parse_user(row)
        save_to_db(user)
    except Exception as e:
        log_error(row, e)

每个用户独立处理，出错就记日志，然后继续下一个。功能上线后跑得很稳，偶尔有格式错误的数据也都记录在案。

后来有个新需求：要导入一批敏感数据，要求“要么全成功，要么全失败”，不能出现部分成功的情况。我想都没想，直接把try挪到了循环外面：

try:
    for row in csv_reader:
        user = parse_user(row)
        save_to_db(user)
except Exception as e:
    rollback_all()
    log_error(e)

第一个版本跑了10万条数据，有3条因为字段缺失失败了，其他都成功。第二个版本，第100条数据因为一个日期格式错误抛异常，整个事务回滚，前99条也白做了。

就在测试环境跑了两轮，我突然意识到：try放在循环里面和外面，执行逻辑、性能、可维护性，完全是天壤之别。这个看似微小的位置差异，背后隐藏着对程序控制流的根本性不同理解。

两种写法，两种世界观

先看try在循环外的样子：

try:
    for item in iterable:
        risky_operation(item)
except Exception as e:
    handle_error(e)

语义非常清晰：整个循环是一个原子操作，一旦其中任何一次迭代抛出异常，循环立即终止，控制流跳到except块。循环后面的代码不会执行。

再看try在循环内：

for item in iterable:
    try:
        risky_operation(item)
    except Exception as e:
        handle_error(e)

语义同样清晰：每次迭代独立运行，某次异常不影响后续迭代。异常被捕获后，循环继续执行下一轮。

这两种写法，没有对错之分，只有场景之别。但搞不清楚背后的机制，就会写出“看着对，跑起来全是问题”的代码。

场景一：批量导入，要容错

这是最常见的需求。你有一堆数据，每条数据之间没有依赖，某条坏了不影响其他。这时候，try放在循环内是唯一正确的选择。

failed_count = 0
for record in records:
    try:
        process(record)
    except ValidationError as e:
        failed_count += 1
        print(f"记录 {record.id} 校验失败: {e}")
        continue
    except DatabaseError as e:
        # 数据库错误可能需要重试
        retry_or_abort(record)
    else:
        print(f"记录 {record.id} 成功")

这段代码有几个关键点：

• 每个异常被捕获后，循环继续，因为continue（其实不写continue也会继续，但写了更明确）
• 不同类型的异常可以分开处理，校验失败就跳过，数据库错误就重试
• 可以统计成功/失败数量，因为循环没有中断

如果把try挪到外面：

try:
    for record in records:
        process(record)
except Exception as e:
    print("全部回滚")

只要有一条数据出错，整个循环就停了，后面的数据连看都不看。这不是“容错”，这是“早停”。而且你根本不知道到底哪条数据出了问题，只能得到一个笼统的异常信息。

场景二：事务操作，要么全有要么全无

但反过来，如果你的操作有“原子性”要求——比如银行转账、订单生成、库存扣减——那try就必须放在循环外面。

def batch_transfer(transfers):
    try:
        for transfer in transfers:
            debit(transfer.from_account, transfer.amount)
            credit(transfer.to_account, transfer.amount)
        commit()
    except Exception:
        rollback()
        raise

这里不能用try在循环内，因为如果你只记录错误然后继续，前面成功的转账已经提交了，后面失败的无法回滚，整个系统就处于不一致状态。

try在循环外时，循环体内的任何异常都会导致except块执行，循环立即终止。 这个特性正好和事务要求的“全部或全不”完美契合。

场景三：有依赖顺序的流水线处理

还有一种情况：循环内每一步的结果是下一步的输入。这时候如果某一步出错，后续步骤都无法进行，也适合把try放在外面。

try:
    for step in pipeline:
        data = step.process(data)
except Exception as e:
    print(f"流水线在第 {step.name} 步中断，当前数据: {data}")
    raise

但有个微妙的地方：如果step.process抛异常，你无法知道是哪个step抛的，除非在异常信息里附带上下文。这里最好的实践是，在循环内部捕获并重新抛出携带更多信息的异常，但最外层的try还是包住整个循环。

性能差别，不是你想的那样

很多人有个误区：认为try放在循环外面比放在里面性能更好，因为每次迭代都有异常捕获的开销。

这个说法对了一半，错了一半。

• 如果循环内没有抛出异常，Python的try块几乎没有额外开销。try只是一个标记，异常捕获的准备工作在编译时就完成了，运行时不会执行任何额外指令。所以你把try放在循环外还是内，在没有异常的情况下，性能差异微乎其微。
• 如果循环内会抛出异常，那性能差异就大了。异常抛出本身是一个重量级操作，Python需要回溯堆栈、查找匹配的except块。这时候无论try放在哪，只要抛异常就慢。但如果你用try在循环内，每次异常都是“抛出->捕获”，而try在外时，一旦异常发生，循环终止，异常只抛出一次。

所以性能不应该成为选择的主要依据。语义正确性优先。

不过有一个小细节：如果你的循环体中有大量的正常逻辑，而异常非常罕见（比如百万分之一），把try放在循环内会稍微增加代码的嵌套层级，但性能上几乎没影响。反之，如果异常频繁发生，try在循环内会让每次异常都被捕获处理，循环继续，但每次都要付出异常开销；而try在外的话，异常一次就终止循环，可能更快——但这是以牺牲容错性为代价的。

还有一个隐藏的大坑：try在循环外时，except块里的变量状态

看这个例子：

try:
    for i in range(10):
        result = 100 // i
        print(result)
except ZeroDivisionError:
    print(f"i = {i} 时出错了")

当i=0时触发异常，循环终止，控制进入except块。此时i的值是0，可以打印出来。但如果你在except块里试图访问result，就会报错NameError，因为result还没来得及定义。这个坑很容易踩。

如果在循环内try：

for i in range(10):
    try:
        result = 100 // i
        print(result)
    except ZeroDivisionError:
        print(f"i = {i} 时出错，跳过")
    # 这里可以继续使用 result？但 result 可能未定义

这就引出了另一个问题：变量作用域。Python没有块级作用域，result在try块内赋值，即使异常发生导致赋值未执行，result仍然存在于外层作用域中（如果之前有定义的话），或者未定义。所以使用时要谨慎。

实际工作中的几个判断标准

我给你总结一套简单的决策逻辑：

问自己三个问题：

1. 一条数据出错，其他数据还要不要处理？ 要 → try放里面；不要 → try放外面。
2. 出错后，你能不能定位到具体是哪条数据？ 如果能，try放里面方便单独记录；如果不能，try放外面可以提前终止避免更多不可控状态。
3. 出错后，之前已经成功的数据是否需要回滚？ 需要 → try放外面（配合事务）；不需要 → try放里面。

这三个问题问完，答案基本就出来了。

组合使用：内部try + 外部try

有时候你既需要单次容错，又需要整体回滚，可以两层结合：

for record in records:
    try:
        try:
            process(record)
        except ValidationError as e:
            log_error(record, e)
            continue
        # 其他严重错误，比如数据库连接断开
    except CriticalError:
        rollback_all()
        break

外层捕获致命错误（比如数据库连接挂了），内层捕获可恢复的业务错误。这样既能保证单条记录出错不影响整体，又能保证极端情况下及时止损。

更精细的控制：finally和else

别忘了try块还有两个好兄弟else和finally。

• else 在try块没有异常时执行，适合放那些依赖try成功执行的后续操作。如果把else放在循环内，每次正常执行都会跑一遍else。
• finally 无论是否异常都会执行，适合放清理资源（关闭文件、释放连接）。循环内外的finally有不同的触发次数——循环内每次迭代都会执行，循环外只在整个循环结束后执行一次。

看一个典型用法（try在循环内）：

for file_path in file_list:
    f = open(file_path, 'r')
    try:
        data = f.read()
        parse(data)
    except ParseError as e:
        log_error(f"文件 {file_path} 解析失败: {e}")
    finally:
        f.close()  # 保证每个文件都被关闭

如果把finally移到循环外，就无法在每个文件处理后及时关闭，可能造成文件句柄泄漏。

一句话总结

try在循环外，是整个循环的“保险丝”——一旦有问题，整体熔断；try在循环内，是每轮迭代的“创可贴”——小伤贴一下，继续干活。

没有哪一种更好，只有哪一种更合适。下次写循环加异常处理时，先停下来想清楚你的业务到底需要“熔断”还是“创可贴”，再做选择。