根本原因是Python在函数定义时确定自由变量绑定但不检查存在性，调用时才查找外层作用域；若变量未定义、未执行到、被del或拼写错误，即报NameError。
为什么闭包里访问变量会报 NameError: name is not defined
根本原因是：Python 在函数定义时就确定了自由变量（free variable）的绑定方式，但不会在定义时检查该变量是否存在；等到调用时才去外层作用域查找。如果外层作用域中该变量未被定义、或定义在条件分支/循环中未执行到、或被 del 删除过，就会触发 NameError。
典型诱因不是“用了闭包”，而是“闭包捕获了一个看似存在、实则未初始化或已失效的名称”。
- 外层函数中变量只在
if分支里定义，但闭包在else或函数末尾被返回 - 用
for循环创建多个闭包，但所有闭包共享同一个循环变量（如i），而循环结束后i可能未定义（尤其在交互式环境或模块顶层） - 外层变量被
del var_name后，闭包仍试图访问它 - 变量名拼写错误，或大小写不一致（比如定义了
user_id，闭包里写了user_ID）
如何快速定位是哪个变量出问题
不要靠猜。直接在闭包函数内部加一句调试输出：
def make_handler():
# 假设这里本该有 user_name = "alice"
def handler():
print("debug: locals =", locals())
print("debug: globals keys =", list(globals().keys())[:10])
return user_name # ← 这里报错
return handler运行后看 locals() 是否为空、globals() 里有没有你期望的变量名。更稳妥的是用 dis.dis(handler) 查看字节码中的 LOAD_DEREF 指令对应哪个名字（它会显示自由变量列表）。
立即学习“Python免费学习笔记（深入）”；
-
import dis后对闭包函数调用dis.dis(handler)，关注Free variables:行 - 如果自由变量列表里有
user_name，但外层没定义它，就一定是定义缺失 - 如果列表为空，说明 Python 没把它识别为自由变量——可能你写成了字符串或硬编码，而非直接引用
修复常见场景：循环中创建闭包时变量丢失
这是最常踩的坑。下面代码在 Python 3.7+ 交互式环境中运行会报 NameError：
funcs = []
for i in range(3):
funcs.append(lambda: i)
print(funcs[0]()) # 输出 2，不是 0；但如果 del i 后再调用，就报 NameError问题不在 i 的值，而在 i 本身是否还存在于外层作用域。修复方式不是“记住值”，而是确保变量名在闭包存活期间始终有效：
- 用默认参数捕获当前值：
lambda x=i: x—— 此时x是局部变量，不依赖外层i - 用嵌套函数明确绑定：
def make_f(val): return lambda: val，然后funcs.append(make_f(i)) - 避免在模块顶层或交互式会话中删掉循环变量；若必须删，改用函数封装整个逻辑，让变量生命周期可控
注意：functools.partial 也能等效替代，但本质仍是把值固化为参数，而非依赖自由变量。
闭包依赖的变量被提前删除或重定义怎么办
比如外层函数里写了 del config_path，之后又返回一个引用 config_path 的闭包，调用时必然失败。Python 不阻止你 del 自由变量，但闭包不会因此自动降级为默认值或空字符串。
- 检查所有
del语句，确认它们不在闭包形成之后执行 - 如果必须动态清理，改用赋值为
None或占位符，而不是del - 对关键配置变量，统一用
getattr(closure, '_config', None)方式防御性访问（需提前用handler._config = config_path绑定） - 更健壮的做法：把依赖项显式传入闭包构造函数，而非隐式捕获 —— 即把闭包变成工厂函数的返回结果，并接受必要参数
真正难调试的，往往不是语法错误，而是变量生命周期和作用域边界的模糊地带。盯住 Free variables 列表，比读十遍作用域规则更管用。
