函数返回多个值时应用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：

• 比如函数本应返回 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
✅ 内存友好
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"{fi
eld}: {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}")

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

# ai  # 的是  # 这是  # 很多人  # 它是  # 大数据  # 多个  # python  # 而非  # 时应  # app  # 按需  # 工具  # js  # json  # Error  # 对象  # int  # 标准库  # bug  # try  # 状态码  # 返回值  # Object  # Attribute  # 遍历  # for  # csv  # sort  # pandas  # append  # union 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】