讲个真事儿。
去年我们做了一个数据迁移工具，要从旧系统导入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仍然存在于外层作用域中（如果之前有定义的话），或者未定义。所以使用时要谨慎。
实际工作中的几个判断标准
我给你总结一套简单的决策逻辑：
问自己三个问题：
- 一条数据出错，其他数据还要不要处理？ 要 → try放里面；不要 → try放外面。
- 出错后，你能不能定位到具体是哪条数据？ 如果能，try放里面方便单独记录；如果不能，try放外面可以提前终止避免更多不可控状态。
- 出错后，之前已经成功的数据是否需要回滚？ 需要 → 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在循环内，是每轮迭代的“创可贴”——小伤贴一下，继续干活。
没有哪一种更好，只有哪一种更合适。下次写循环加异常处理时，先停下来想清楚你的业务到底需要“熔断”还是“创可贴”，再做选择。
