Python 函数返回值优化技巧

陆砚码

2026-09-15 • 👁 4人浏览过

函数返回多个值时应用tuple而非list，因逗号分隔返回值本质是tuple；None需显式写出；大数据用yield生成器；错误应抛异常而非返回状态码。函数返回多个值时，别用 list 而要用 tuple Python 中用逗号分隔多个返回值（如

return a, b, c

）实际返回的是 tuple，不是 list。这是语言特性，但很多人误以为是“语法糖”，后续却用

.append()

或

.sort()

去操作它，立刻报

AttributeError: 'tuple' object has no attribute 'append'

。真正需要可变容器时才显式构造 list；否则保持 tuple 更安全、更轻量，也暗示“这组值不应被修改”：

def get_user_info():
    return "alice", 28, "engineer"  # ← 返回 tuple，解包自然：name, age, role = get_user_info()
❌ 错误假设它是 list
result = get_user_info()
result.append("remote")  # TypeError！
✅ 正确做法：按需转 list

result_list = list(get_user_info()) + ["remote"]

None 返回值要显式写出，别依赖隐式返回函数末尾无

return

语句时，Python 自动补

return None

。但这会让调用方难以区分“逻辑未覆盖”和“明确无结果”。尤其在条件分支中，漏写

return

容易引发静默 bug：立即学习 “ Python免费学习笔记（深入） ”；比如函数本应返回

int

，但某个分支忘了

return

，调用方拿到

None

后做算术运算直接抛

TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

类型提示（

-> int

）和静态检查工具（如 mypy）会报错建议所有分支都显式返回，或在函数末尾加兜底

return None

并配类型注解：

def find_first_even(numbers: list[int]) -> int | None:
    for n in numbers:
        if n % 2 == 0:
            return n
    return None  # ← 明确写出，不省略

大对象返回前考虑 yield 或生成器当函数要返回大量数据（如读取数万行 CSV、遍历深层嵌套结构），一次性构造 list 会吃光内存。此时应改用

yield

返回生成器： php版微信js-sdk支付接口类 php版微信js-sdk支付接口类下载

yield

不是“优化技巧”，而是内存模型的根本切换：从“全量加载”变为“按需产出” 调用方用

for item in func()

或

list(func())

按需消费，不强制展开若下游必须用 list（比如传给 pandas），再显式转换，责任清晰示例：过滤大文件中的有效行

def read_valid_lines(filepath: str) -> Generator[str, None, None]:
    with open(filepath) as f:
        for line in f:
            stripped = line.strip()
            if stripped and not stripped.startswith("#"):
                yield stripped  # ← 不构建大 list
✅ 内存友好
for line in read_valid_lines("huge.log"):
process(line)
❌ 避免这样

`all_lines = list(read_valid_lines("huge.log")) # 可能 OOM`

避免在返回值里塞状态码或错误信息像

return {"success": True, "data": ..., "error": None}

这类“胖返回值”看似统一，实则破坏 Python 的错误处理契约：异常该抛就抛，成功就干净返回业务数据。调用方必须每处都检查

resp["success"]

，容易遗漏，且无法用

try/except

统一捕获类型提示难写（

Union[SuccessResp, ErrorResp]

），mypy 支持弱和标准库、主流框架（requests、sqlite3）风格冲突，增加协作成本正确做法：成功路径直接返回核心数据；失败路径抛出带语义的异常（如

ValueError

、自定义

ParseError

），必要时在异常对象上挂附加信息：

class ValidationError(Exception):
    def __init__(self, field: str, message: str):
        self.field = field
        self.message = message
        super().__init__(f"{field}: {message}")

def parse_config(config_str: str) -> dict: try: return json.loads(config_str) except json.JSONDecodeError as e: raise ValidationError("config_json", f"invalid syntax at line {e.lineno}")

返回值越单一、越符合直觉，调用方就越不容易写出防御性垃圾代码。真正难处理的，从来不是返回什么，而是没想清楚“什么算成功、什么算失败”。

❌ 错误假设它是 list

result = get_user_info()

result.append("remote") # TypeError！

✅ 正确做法：按需转 list

✅ 内存友好

❌ 避免这样

all_lines = list(read_valid_lines("huge.log")) # 可能 OOM

相关文章

`all_lines = list(read_valid_lines("huge.log")) # 可能 OOM`