开场钩子

一次流式模型调用只返回了 a、c，b 像凭空消失。没有网络错误，没有异常堆栈，消费者只是正常地写了一个 for 循环，又在循环体里多调用了一次next()。另一个装饰器测试显示绿色，日志却在模块导入时打印，而不是业务调用时打印。真正危险的不是 “不会写语法”，而是执行时机、状态归属和异常边界与直觉不一致。函数不只是代码块，而是可组合、可观察、有契约的生产对象。

说明：带时间戳的服务日志为教学模拟，用于说明生产故障形态，不冒充真实公司事故。

本文地图

• 用位置、关键字、默认值、斜杠和星号设计稳定的公共函数接口。
• 理解函数对象、闭包、Iterator、Generator 和 Decorator 的创建与执行时机。
• 识别重复消费、延迟异常、晚绑定、元数据丢失和盲目重试。
• 将这些机制映射到模型 SDK 包装、RAG 流水线、Tracing 和流式响应。
• 获得一份函数与惰性数据流的生产审查 Checklist。

生产落地速查

表格

一、参数契约：斜杠和星号不是标点

a. 一句话本质

函数签名不仅接收数据，还规定调用方必须怎样表达意图。

b. 人话类比

函数参数像快递面单。位置参数是 “从左到右固定格子”，关键字参数是 “每个格子写了字段名”。斜杠和星号则是柜台规则：某些信息只能按位置交，某些必须喊出名字，避免把两个长得一样的数字塞反。

c. 最小可复现示例

def format_retry_policy( attempts: int, /, *, delay_seconds: float, ) -> str: if attempts <= 0: raise ValueError("attempts must be greater than 0") if delay_seconds < 0: raise ValueError( "delay_seconds must be greater than or equal to 0" ) return ( f"attempts={attempts}, " f"delay_seconds={delay_seconds}" ) print(format_retry_policy(3, delay_seconds=0.5))

斜杠前的attempts只能按位置传；星号后的delay_seconds必须按关键字传。对 timeout、temperature、stream、retry 等同类型配置，这能显著提高代码审查可读性。

安全默认值：

def add_optional_prefix(text: str, prefix: str = "") -> str: return text if not prefix else f"{prefix}: {text}"

字符串不可变，适合作默认值。list、dict等可变默认值会在多次调用之间共享。

d. 生产事故现场

教学模拟：模型 SDK 包装器接受多个数字位置参数，调用方把temperature和timeout传反。

2026-10-30 09:14:22,101 [answer-api-3] ModelRequest INFO model=quality temperature=30 timeout_seconds=0.2 2026-10-30 09:14:22,105 [answer-api-3] Validation ERROR field=temperature value=30 allowed="[0,2]" 2026-10-30 09:14:22,106 [answer-api-3] HttpHandler WARN status=400 request_id=req-901

影响面可能只是一个请求失败，也可能因为布尔值和整数可互换而产生 “语法合法、业务错误” 的调用。

e. 排查过程

1. T+0：打印函数签名和实际调用。不先怀疑模型服务。
2. T+3 分钟：按参数绑定规则逐项对齐。
3. T+6 分钟：检查默认值是否在定义时创建。
4. T+10 分钟：把同类型、容易互换的配置改成仅关键字。
5. T+15 分钟：补错误调用测试，确保 Python 在边界直接 TypeError。

f. 根因分析

Python 在进入函数体之前完成参数绑定。默认参数表达式在def执行时求值，而不是每次调用时求值，因此默认list会成为跨调用共享对象。

斜杠和星号改变的是调用契约，不改变运行时值本身。它们让错误更早、更靠近调用方暴露。公共 API 的字段名若未来可能重命名，有时会用仅位置参数避免调用方绑定名字；业务配置更常使用仅关键字参数提升可读性。

g. 修复方案

表格

不是所有参数都要关键字化。高频、含义稳定、自然顺序明确的核心值可保留位置参数；配置项和布尔开关更适合关键字。

h. 预防与规范

• 公共函数签名在评审中视为 API，不是实现细节。
• 禁止可变默认参数，除非明确利用共享状态并有充分说明。
• 模型请求在本地校验空字符串、Token 上限、温度和超时。
• 测试覆盖位置误传、关键字遗漏、边界值和默认值隔离。
• 日志记录字段名和值范围，不记录完整 Prompt。
• 修改参数名或调用方式时评估兼容性。

i. 进阶延伸

1. inspect.signature可以在框架、依赖注入和装饰器中读取参数契约。
2. Java 依赖重载和 Builder 表达调用方式；Java 没有 Python 同等级别的命名实参，Builder 在配置多时更常见。

二、args 与 kwargs：透明转发最怕偷偷改语义

a. 一句话本质

定义处星号收集参数，调用处星号展开参数。

b. 人话类比

*args像把散装包裹装进一个按顺序排列的箱子，**kwargs像把贴着字段名的包裹装进字典。转发时再把箱子拆开，按原标签交给下一站。

c. 最小可复现示例

from collections.abc import Callable from typing import Any def merge_request_options( base: dict[str, object], **overrides: object, ) -> dict[str, object]: return {**base, **overrides} def forward_call( handler: Callable[..., str], *args: Any, **kwargs: Any, ) -> str: return handler(*args, **kwargs) base = {"model": "fast", "temperature": 0.2} merged = merge_request_options(base, temperature=0.7, stream=True) print(base) print(merged)

预期输出：

{'model': 'fast', 'temperature': 0.2} {'model': 'fast', 'temperature': 0.7, 'stream': True}

d. 生产事故现场

教学模拟：中间件转发模型调用时漏掉 timeout，导致请求使用 SDK 默认值，连接长时间占用。

2026-11-02 11:22:17,301 [api-worker-2] ModelMiddleware INFO forwarded_args=1 forwarded_kwargs=2 2026-11-02 11:22:47,306 [api-worker-2] PoolMonitor WARN active_connections=100 available=0 2026-11-02 11:22:47,307 [api-worker-2] RequestTimeout ERROR configured_timeout=5 actual_elapsed=30

另一个风险是中间件吞掉返回值或异常，让调用方收到None，真实故障却被掩盖。

e. 排查过程

1. T+0：记录键名集合，不记录敏感值。
2. T+3 分钟：对照包装前后的 args 长度和 kwargs 键。
3. T+6 分钟：检查return handler(*args, **kwargs)是否完整。
4. T+9 分钟：验证下游异常能否原样穿透。
5. T+12 分钟：检查合并是否修改 base。

f. 根因分析

定义时*args形成tuple，**kwargs形成dict。调用时*iterable按位置展开，**mapping按关键字展开。

参数转发的目标是透明：不丢参数、不改顺序、不吞返回值、不隐藏异常。若包装层确实要改写配置，应在名称、类型和日志中明确，而不是伪装成透明转发。

字典合并具有顺序覆盖语义。{**base, **overrides}创建新 dict；base.update(overrides)原地修改，二者生产影响不同。

g. 修复方案

• 临时止血：显式补传 timeout 和 retry 参数。
• 根本修复：中间件统一使用*args、**kwargs转发，并增加契约测试。
• 需要禁止任意字段时，不要无条件接收**kwargs；用显式签名或白名单验证。
• 类型安全要求高时使用ParamSpec保留原函数签名，这是后续进阶内容。

h. 预防与规范

• 转发测试覆盖位置参数、关键字参数、返回值和异常。
• 配置合并测试断言 base 未改变。
• 不在日志中打印完整 kwargs，避免 Prompt、Token 或密钥泄漏。
• 同一键多次提供时，让 Python 自己报 TypeError，不做静默猜测。
• 公共 SDK 封装优先显式参数；通用装饰器和适配器才使用可变参数。

i. 进阶延伸

1. ParamSpec与TypeVar能让 Pyright 理解 “包装前后签名一致”。
2. Java 的Object...只对应可变位置参数；命名参数通常通过 Map、Builder 或配置对象表达。

三、函数是一等对象：把策略交给调用方

a. 一句话本质

函数可以像数据一样被传入、返回、保存和组合。

b. 人话类比

高阶函数像一条固定生产线，调用方可以更换 “清洗头”“排序尺” 和 “过滤网”，不用为每种策略复制整条流水线。

c. 最小可复现示例

from collections.abc import Callable def apply_transform( text: str, transform: Callable[[str], str], ) -> str: return transform(text) def sort_by_latency( records: list[tuple[str, int]], ) -> list[tuple[str, int]]: return sorted(records, key=lambda record: record[1]) def compose( first: Callable[[str], str], second: Callable[[str], str], ) -> Callable[[str], str]: return lambda text: second(first(text)) normalize = compose(str.strip, str.lower) print(apply_transform(" AI ", normalize))

预期输出：

ai

注意compose的顺序是second(first(text))，不是反过来。

d. 生产事故现场

教学模拟：RAG 流水线组合顺序写反，先切块再清洗，导致重复空白进入向量化，切块边界和测试环境不一致。

2026-11-02 13:07:18,801 [rag-worker-1] ChunkPipeline INFO source_chars=12000 chunks=88 2026-11-02 13:07:18,812 [rag-worker-1] QualityCheck WARN empty_chunks=6 duplicate_chunks=9 2026-11-02 13:07:18,814 [rag-worker-1] PipelineConfig ERROR expected_order=normalize_then_split actual_order=split_then_normalize

影响面包括向量成本上涨、召回噪声增加和离线 / 在线结果不一致。

e. 排查过程

1. T+0：打印每个阶段的输入输出摘要。
2. T+4 分钟：把组合函数展开为中间变量。
3. T+7 分钟：区分传函数transform与调用结果transform(text)。
4. T+10 分钟：检查排序 key 和稳定性。
5. T+14 分钟：用非交换函数测试顺序。不能用两种顺序结果恰好相同的示例。

f. 根因分析

Pythondef创建函数对象；名称只是指向该对象。写transform传递函数，写transform(text)立即调用并传递结果。

Callable[[str], str]描述输入输出契约，但不会自动验证函数是否纯净或是否有副作用。lambda适合简单表达式，不支持复杂语句，也不应承载难以调试的业务流程。

sorted的 key 函数对每个元素计算排序键。稳定排序让相同延迟的记录保持原顺序，对按时间到达的数据很重要。

g. 修复方案

• 临时止血：调整 compose 顺序，并在日志中记录 pipeline 版本。
• 根本修复：每个阶段保持单一职责，组合函数写独立测试。
• 简单 key 使用 lambda；复杂规则使用具名函数。
• 需要依赖外部服务的策略通过接口或对象注入，不把网络副作用藏进排序 key。

h. 预防与规范

• 流水线配置记录阶段名称和顺序。
• 高阶函数类型注解写清 Callable 输入输出。
• 组合测试使用顺序敏感的示例。
• 排序函数默认返回新 list，不修改调用方输入。
• lambda 控制在一眼可读的表达式内。
• 监控各阶段输入数、输出数、耗时与丢弃数。

i. 进阶延伸

1. functools.partial可以预绑定部分参数，适合生成配置化回调。
2. Java Lambda、Function、Comparator 与 Python Callable 对应，但 Python 函数对象拥有更直接的运行时元数据和闭包能力。

四、闭包与 nonlocal：状态被函数背在身上

a. 一句话本质

闭包让内部函数在外层函数结束后继续访问其环境。

b. 人话类比

闭包像外卖员随身背着一个小包。餐厅已经关门，包里的地址、前缀和计数器仍然跟着外卖员。nonlocal则是允许他更新包里的便签，而不是在手里另写一张同名便签。

c. 最小可复现示例

from collections.abc import Callable def make_prefixer(prefix: str) -> Callable[[str], str]: def prefix_text(text: str) -> str: return f"{prefix}: {text}" return prefix_text def make_call_counter() -> Callable[[], int]: count = 0 def next_count() -> int: nonlocal count count += 1 return count return next_count warn = make_prefixer("WARN") counter_a = make_call_counter() counter_b = make_call_counter() print(warn("timeout")) print(counter_a(), counter_a(), counter_b())

预期输出：

WARN: timeout 1 2 1

每次调用工厂函数都会创建独立闭包环境。

d. 生产事故现场

一个可复现错误是：前缀函数把prefix和text顺序写反。类型都是 str，类型检查无法发现业务字段交换。

expected: WARN: timeout actual: timeout: WARN

教学模拟的另一个事故：把闭包计数器当成全局请求计数器，多进程部署后每个进程都有独立值，监控总量严重偏低。

2026-11-02 15:20:00,000 [worker-1] RequestCounter INFO count=102 2026-11-02 15:20:00,000 [worker-2] RequestCounter INFO count=97 2026-11-02 15:20:01,000 [dashboard] RequestCounter WARN displayed_total=102 expected_min=199

e. 排查过程

1. T+0：先检查业务字段顺序，而不只看类型。
2. T+3 分钟：查看函数的自由变量和创建位置。
3. T+7 分钟：确认每个实例是否应共享状态。
4. T+10 分钟：区分读取外层名称与重新绑定名称。
5. T+14 分钟：评估线程、多进程和重启后的状态语义。

f. 根因分析

名称查找遵循 LEGB：Local、Enclosing、Global、Builtins。内部函数读取外层不可变值不需要nonlocal；要执行count += 1这类重新绑定时必须声明nonlocal，否则 Python 会把count当局部变量，读取时出现UnboundLocalError。

修改外层可变对象内容通常不需要nonlocal，因为名称没有重新绑定。循环变量晚绑定则意味着多个闭包可能都读取循环结束后的最终值，可通过默认参数冻结当前值。

闭包状态只存在当前进程内，不持久、不分布式，也不自动线程安全。

g. 修复方案

• 前缀错位：修正格式模板并增加字段顺序测试。
• 短生命周期局部计数：闭包足够简单。
• 跨线程共享：使用锁或并发安全组件，并验证复合操作。
• 跨进程 / 持久状态：使用数据库、Redis 或指标系统，不用闭包冒充。
• 复杂状态和多种行为：升级为类，让状态更可观察。

h. 预防与规范

• 闭包工厂名称体现它会创建独立状态。
• 测试两个闭包实例互不影响。
• 对同类型字段使用具体示例验证顺序。
• 不在闭包中长期持有大对象、连接或敏感数据。
• 循环创建回调时检查晚绑定。
• 生产状态设计明确进程、线程、持久化和重启边界。

i. 进阶延伸

1. function.__closure__和inspect可观察闭包，但业务代码不应依赖内部布局。
2. Java Lambda 也能捕获外部变量，但通常要求局部变量 effectively final；Pythonnonlocal允许重新绑定外层名称。

五、Iterable 与 Iterator：消费一次就是一次

a. 一句话本质

Iterable能产生迭代器，Iterator自己保存 “走到哪里” 的状态。

b. 人话类比

list像一本书，可以反复从第一页翻；Iterator像检票口的一卷票，撕掉一张就少一张，不会自动卷回去。

c. 最小可复现示例

from collections.abc import Iterable, Iterator def take_first(values: Iterable[str], limit: int) -> list[str]: if limit < 0: raise ValueError("limit 必须大于等于 0") iterator = iter(values) result: list[str] = [] for _ in range(limit): try: result.append(next(iterator)) except StopIteration: break return result def consume_twice( values: Iterator[str], ) -> tuple[list[str], list[str]]: return list(values), list(values) print(consume_twice(iter(["a", "b"])))

预期输出：

(['a', 'b'], [])

d. 生产事故现场

一个可复现错误是：take_first同时使用for item in values和next(values)。for 已经调用一次 next，循环体又调用一次，于是数据被双重消费，输出 a、c，并在尾部意外StopIteration。

captured stdout: a c E StopIteration stream_reader.py: next(values)

自定义倒计时还出现 “先减再返回”，CountdownIterator(3)得到[2, 1, 0]而不是[3, 2, 1]。

e. 排查过程

1. T+0：记录每次 next 前后的状态。
2. T+3 分钟：确认是谁负责消费。for、list、sum 都会消费。
3. T+6 分钟：搜索同一循环中的显式 next。
4. T+9 分钟：用仅含 3 个元素的小输入复现。
5. T+12 分钟：检查返回前是否更新状态，定位 off-by-one。
6. T+15 分钟：验证耗尽后重复 next 仍抛 StopIteration。

f. 根因分析

for 循环近似执行：

iterator = iter(values) while True: try: item = next(iterator) except StopIteration: break # 循环体

Iterable只保证__iter__，不保证自己有__next__。因此任意Iterable应先iter(values)，再对得到的Iterator调 next。

Iterator.__iter__通常返回 self。状态更新顺序必须是 “保存本次值 → 推进状态 → 返回保存值”。

g. 修复方案

表格

不要为了重复遍历无限流而强行 list 化。那会把单次消费问题变成内存问题。

h. 预防与规范

• 函数签名明确接收Iterable还是Iterator。
• 同一数据流只有一个明确消费方。
• 测试limit=0时不消费任何元素。
• 参数在消费前校验，避免非法调用产生副作用。
• 数据库游标、文件和流式响应记录已消费位置。
• 不把Iterator传给两个都期待完整数据的消费者。

i. 进阶延伸

1. itertools.islice可以实现按需截取，但仍要理解它会推进原迭代器。
2. JavaIterable与Iterator分工相近；Python 协议更轻量，任何实现对应魔术方法的对象都能参与迭代。

六、Generator 与 yield：错误也会被延迟

a. 一句话本质

生成器用yield保存执行现场，并在消费时按需运行。

b. 人话类比

普通函数像整桌菜做好再上；生成器像现点现做，每次端一盘后暂停。好处是不占满桌子，代价是第八盘食材坏了，要吃到第八盘才知道。

c. 最小可复现示例

from collections.abc import Iterator def generate_batches( items: list[str], batch_size: int, ) -> Iterator[list[str]]: if batch_size <= 0: raise ValueError("batch_size 必须大于 0") for start in range(0, len(items), batch_size): yield items[start : start + batch_size] def running_totals(values: list[int]) -> Iterator[int]: total = 0 for value in values: total += value yield total print(list(generate_batches(["a", "b", "c"], 2))) print(list(running_totals([2, 3, -1])))

预期输出：

[['a', 'b'], ['c']] [2, 5, 4]

含yield的函数调用只创建 generator。参数校验位于函数体时，也要到第一次消费才执行。

d. 生产事故现场

一个常见边界问题是：batch_size=0会碰巧由range抛ValueError，但负数可能直接产生空序列，未满足 “所有小于等于 0 都拒绝” 的业务契约。

batch_size=0 -> ValueError: range() arg 3 must not be zero batch_size=-1 -> []

教学模拟：JSONL 第 80 万行损坏，任务在创建生成器时显示成功，消费到该行才失败。

2026-11-03 02:00:00,001 [rag-import-1] ImportJob INFO generator_created=true 2026-11-03 02:41:22,719 [rag-import-1] JsonParser ERROR line_number=800214 reason=invalid_json 2026-11-03 02:41:22,720 [rag-import-1] ImportJob WARN committed_batches=781 partial=true

e. 排查过程

1. T+0：区分创建阶段和消费阶段日志。
2. T+4 分钟：定位最后成功 yield 的批次和偏移。
3. T+8 分钟：检查参数校验是否依赖底层函数偶然报错。
4. T+12 分钟：确认客户端提前停止时资源是否关闭。
5. T+16 分钟：复现空输入、负值、中途异常和只消费第一项。

f. 根因分析

yield把值交给调用方，同时冻结指令位置、局部变量和异常处理状态。下一次next从yield后继续。函数正常结束转换为StopIteration。

惰性降低峰值内存和首条结果延迟，但计算成本仍存在。异常、日志和资源释放也被推迟。若生成器在with open内暂停，文件会保持打开直到生成器耗尽、关闭或执行清理。

生成器只能消费一次。生成器表达式适合简单流水线；复杂状态、异常隔离和资源管理更适合具名生成器函数。

g. 修复方案

• 显式校验batch_size <= 0，不依赖 range 的错误。
• 每批记录 batch_id、起止偏移和幂等键。
• 使用try/finally清理生成器内部资源。
• 客户端断开时关闭上游模型流，避免继续计费和占连接。
• 小数据且需重复遍历时返回 list，不为了 “高级” 强用生成器。

h. 预防与规范

• 日志区分generator_created、consumption_started、completed、closed。
• 测试异常发生在创建还是消费阶段。
• 批处理设计检查点和幂等重跑。
• 监控打开连接数、活跃生成器数、首元素延迟和完成率。
• 资源所有权写进接口：谁创建、谁消费、谁关闭。
• 不在 generator 中长期保留完整 Prompt 或大对象。

i. 进阶延伸

1. yield from可委托子迭代器，还能传递StopIteration.value；使用前要理解异常传播。
2. Java Stream 与生成器都惰性，但 Pythonyield能在普通控制流中暂停函数；Java 通常通过 Stream/Iterator 状态机表达。

七、Decorator 与 wraps：横切逻辑不能改掉原函数身份

a. 一句话本质

装饰器在定义阶段替换函数，包装器在调用阶段执行附加逻辑。

b. 人话类比

装饰器像给员工安排一名前台。前台可以登记来访和计时，但名片上仍应保留真实员工姓名。忘记wraps后，系统里所有人都叫 wrapper，出了事像监控只告诉你 “某个前台挂了”。

c. 最小可复现示例

from collections.abc import Callable from functools import wraps def trace_call( func: Callable[[], str], ) -> Callable[[], str]: @wraps(func) def wrapper() -> str: print(f"calling {func.__name__}") return func() return wrapper def retry_value_error( attempts: int, ) -> Callable[[Callable[[], str]], Callable[[], str]]: if attempts <= 0: raise ValueError("attempts必须大于0") def decorator( func: Callable[[], str], ) -> Callable[[], str]: @wraps(func) def wrapper() -> str: for _ in range(attempts - 1): try: return func() except ValueError: continue return func() return wrapper return decorator

@retry_value_error(3)等价于retry_value_error(3)(原函数)，所以带参数装饰器需要 “配置层 → 接收函数层 → 调用包装层” 三层。

d. 生产事故现场

一个可复现错误是：trace_call在装饰阶段立即打印并直接返回原函数。测试碰巧在函数定义后才读取 capsys，因此显示通过，却没有证明日志发生在调用阶段。

首次专项测试: trace_call: PASSED require_non_empty: PASSED retry_value_error: FAILED Ruff: F821 Undefined name 'func' Pyright: Function accepts too few positional parameters

测试绿了但契约没满足，是比红灯更值得警惕的信号。

e. 排查过程

1. T+0：在装饰前、装饰后、调用前、调用后分别记录事件。
2. T+4 分钟：展开@decorator为func = decorator(func)。
3. T+7 分钟：检查 wrapper 是否return func(...)。
4. T+10 分钟：检查__name__、__doc__和__wrapped__。
5. T+13 分钟：展开带参数装饰器三层结构。
6. T+17 分钟：补最终失败、非目标异常和非法次数测试。

f. 根因分析

模块执行到def后立刻应用装饰器；wrapper 内代码才在业务调用时运行。把 print 写在装饰器外层会在 import 时产生副作用。

functools.wraps复制名称、文档、注解等元数据，并设置__wrapped__。它影响日志、帮助、测试和框架反射。

重试只应捕获明确可恢复的异常。attempts是总尝试次数，不是额外次数。最后一次直接调用能让最终异常原样传播，并避免为了满足类型检查引入伪返回值。

装饰器顺序从下往上应用。@trace在@retry外层看到一次总调用；放在内层会看到每次尝试。两者指标含义不同。

g. 修复方案

表格

不是所有横切逻辑都适合装饰器。若它会显著改变返回类型、控制流或领域含义，显式服务对象通常更容易理解。

h. 预防与规范

• 装饰器默认使用 wraps。
• 测试区分装饰阶段和调用阶段。
• 包装器保留返回值与异常语义。
• 重试只捕获白名单异常，并限制总次数和总时间。
• 非幂等写操作必须有幂等键，不能盲目重试。
• Tracing 不记录完整 Prompt、密钥和用户隐私。
• 多层装饰器的顺序写入测试和指标说明。

i. 进阶延伸

1. ParamSpec可以让通用装饰器精确保留任意函数签名。
2. Java Spring AOP 常由代理解释注解；Python 装饰器直接转换函数对象。Java 自调用绕过代理等问题与 Python 包装顺序问题不同，但都要求理解调用链。

横向串联：函数能力如何组成 AI 调用链

表格

一条典型模型调用链可以是：

参数契约 → 配置合并与透明转发 → 注入预处理策略 → 生成器按批读取文档 → Iterator 单一消费者提交请求 → 装饰器记录耗时并有限重试 → 流式结果按需返回

每一层都必须保留上一层的返回值、异常和资源所有权。所谓 “Pythonic”，不是代码越短越好，而是协议和意图对得上。

生产 Checklist 汇总

函数签名

• 同类型配置是否改为仅关键字参数？
• 是否存在 list/dict/set 可变默认值？
• 参数在产生副作用前完成校验？
• 返回类型与所有控制路径一致？

转发与高阶函数

• *args、**kwargs是否完整转发？
• 包装层是否返回原调用结果并保留异常？
• 配置合并是否修改了 base？
• 函数对象与函数调用结果没有混淆？
• 组合顺序使用顺序敏感测试验证？

闭包状态

• 需要重新绑定的外层名称使用nonlocal？
• 两个闭包实例是否相互隔离？
• 循环创建回调是否处理晚绑定？
• 没有把闭包当持久化或分布式状态？

迭代与生成器

• Iterable先iter()后再next()？
• 同一Iterator只有一个明确消费者？
• limit=0不会消费任何数据？
• generator 的参数错误在哪个阶段抛出已测试？
• 中途异常和提前停止能释放文件、连接和上游流？
• 需要重复遍历时没有误用一次性 generator？

装饰器与重试

• 使用@wraps(func)保留元数据？
• 装饰阶段没有网络、打印或业务副作用？
• 带参数装饰器具备正确三层结构？
• attempts是总次数还是额外次数已写清？
• 只重试明确可恢复异常？
• 非幂等操作具备幂等键？
• 装饰顺序对应的监控含义已说明？

测试与可观测性

• 测试能区分创建、装饰、调用和消费阶段？
• 不只看绿灯，还检查测试是否覆盖真实契约？
• Ruff、格式检查、Pyright 和 pytest 全部进入 CI？
• 日志包含 request_id、阶段和失败类别，不泄露 Prompt？

结尾

一句话方法论：先问代码 “什么时候执行、谁保存状态、谁消费数据、异常在哪里出现”，再写函数；时机和所有权一旦说清，装饰器、生成器和闭包就不再神秘。