函数是封装可复用逻辑的最小执行单元，用于解决重复代码、隐藏实现细节、降低调试难度；必须在参数化行为和接口隔离场景下使用，并避免设计陷阱如返回值不一致、副作用不可控等。
函数是用来封装可复用逻辑的最小执行单元
Python 中的 function 不是语法糖，也不是为了“看起来更专业”，而是解决重复代码、隐藏实现细节、降低调试难度的刚需工具。你写两遍以上相同逻辑（比如解析 JSON、校验手机号、拼接 SQL），就该立刻抽成函数；否则后续改一处漏一处，出问题时根本不知道哪段逻辑被复制粘贴歪了。
什么时候必须用函数：参数化行为和接口隔离
当一段代码需要根据输入产生不同结果，又不能靠全局变量或硬编码切换时，def 就是唯一干净解法。比如日志记录级别、数据库连接池选择、API 请求重试策略——这些都不能写死，但也不能每次调用都重复 if-else 堆砌。
- 避免用字符串拼接构造 SQL，改用带
params参数的cursor.execute(sql, params)函数封装 - 处理 CSV 文件时，不要在主流程里反复写
open()+csv.reader()+ 异常捕获，而应封装为read_csv_file(filepath, encoding="utf-8") - HTTP 请求若需统一加 token、超时、错误重试，必须抽成
make_api_request(url, method="GET", timeout=5)，而不是每个地方都调requests.get()
容易被忽略的函数设计陷阱
很多初学者写的函数看似能跑，实则埋雷：返回值类型不一致、副作用不可控、参数耦合过重。最典型的是把文件路径、配置字典、状态标记全塞进参数列表，导致调用时要传七八个参数，还分不清哪些是必填哪些是默认。
- 函数名要动词开头：
parse_config()比config_parser()更准确，后者像类名 - 避免修改传入的可变对象（如
list或dict），除非函数名明确体现（如sort_inplace(items)） - 不要让函数同时做「读文件」+「校验格式」+「写日志」+「发告警」——拆成
load_data()、validate_data()、log_error()等独立单元 -
return语句尽量统一位置，别一半路径 return 字符串，另一半 return None；否则调用方容易误判返回值类型
def safe_json_load(filepath):
try:
with open(filepath, "r", encoding="utf-8") as f:
return json.load(f)
except FileNotFoundError:
logging.warning(f"Config file not found: {filepath}")
return {}
except json.JSONDecodeError as e:
logging.error(f"Invalid JSON in {filepath}: {e}")
return {}
函数不是万能的：什么情况不该硬套
单行表达式、仅调用一次且无参数变化、纯副作用操作（如 print("done")），强行封装函数反而增加阅读负担。Python 的 lambda 在 map()、sorted(key=...) 场景下更轻量；而真正复杂的流程控制，应该考虑类或模块划分，而非堆砌几十个零散函数。
立即学习“Python免费学习笔记（深入）”；
很多人卡在“到底该不该封装”上，其实就看一点：下次遇到同样需求，你是想复制粘贴这段代码，还是希望直接 import 后调用？前者就该封装，后者就别动。
