函数返回多个值时应用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()
<h1>❌ 错误假设它是 list</h1><h1>result = get_user_info()</h1><h1>result.append("remote") # TypeError！</h1><h1>✅ 正确做法：按需转 list</h1><p>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 返回生成器：
-
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
<h1>✅ 内存友好</h1><p>for line in read_valid_lines("huge.log"):
process(line)</p><h1>❌ 避免这样</h1><h1>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}")
<p>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}")返回值越单一、越符合直觉，调用方就越不容易写出防御性垃圾代码。真正难处理的，从来不是返回什么，而是没想清楚“什么算成功、什么算失败”。
