循环闭包问题核心是变量共享与内存泄漏：用默认参数或partial固化变量值，避免捕获大对象，显式传参替代隐式闭包，及时清理强引用，必要时对依赖对象使用弱引用。
在循环中创建闭包时，最容易出现两个问题：一是所有闭包共享同一个变量值（循环变量陷阱），二是每个闭包都强引用了外层的大对象，导致内存堆积。关键不是“去掉闭包”，而是让闭包轻量、可控、不拖累资源。
用默认参数固化当前值，避免变量复用
循环变量（如 i）在闭包中不是按迭代快照保存的，而是被所有闭包共同引用——等循环结束，它们全指向最终值。最直接的修复是把当前值“冻结”进函数定义里：
- 写成
lambda x=i: x * x，而不是lambda: i * i - 或用
functools.partial(func, i)绑定参数，语义更清晰 - 不要依赖
time.sleep或异步延迟来“等值稳定”，那只是掩盖问题
大对象别闭包捕获，改用显式传参
如果闭包需要访问配置、模型、连接池等大对象，千万别让它自然闭包捕获整个变量（比如 config 或 self）。一旦协程挂起或任务长期存活，这些对象就卡在内存里出不去：
- 把
async def handler(): return api_call(url)改为async def handler(url, session, cache): ... - 类方法中，只提取真正需要的字段：
client = self.client; timeout = self.timeout，再传入协程 - 避免
lambda: self.process()这类写法——它隐式持有了整个self
及时清理强引用，防止协程/闭包滞留
闭包本身不可怕，可怕的是它被长期持有却没人回收。尤其在异步场景下，create_task() 返回的 Task 是强引用，若没 await 也没 cancel，它和它闭包里的对象都会一直活着：
- 批量启动任务时加限流，别一次性
[asyncio.create_task(f(i)) for i in huge_list] - 任务存到列表后，完成就
del task_list[idx]或用weakref.WeakSet - 调试时可用
inspect.getclosurevars(coro)查看实际捕获了哪些变量
必要时用弱引用解耦，但别弱引闭包本身
弱引用不是万能膏药，也不能用来包装闭包函数（多数闭包不支持弱引用）。真正该弱引的，是闭包所依赖的那个外部对象：
- 比如回调中要用
widget.update()，就存weakref.ref(widget)，调用前先判断if ref(): ref().update() - 对绑定方法，优先用
weakref.WeakMethod(obj.method)，比手写闭包 +weakref.ref(obj)更可靠 - 避免
weakref.ref(lambda: obj.do())—— lambda 创建时已强绑obj，弱引毫无意义
