很多人学 Python 的时候都会有这么一段经历基本语法看完了循环、判断、列表推导也都能写可真要自己做个小脚本、写点业务逻辑就总感觉无从下手。我这些年被问得最多的一个问题不是“列表和元组有什么区别”而是“函数到底该怎么用”。Python 函数看着简单但真正决定你能不能写出可维护代码的恰恰是那些藏在细节里的门道参数怎么传、默认值为什么不能写列表、闭包和装饰器到底在干什么。这篇文章我会从 def 的基本骨架一路讲到 *args、闭包、装饰器和回调函数把 Python 函数这条线完整地捋一遍。不管你是刚入门想要打基础还是写过一阵子代码但总觉得自己对函数的理解还差点意思这篇内容都值得你安静读完。1. 为什么 Python 函数是项目的地基而非“语法糖”1.1 函数解决的不只是“重复代码”很多初学者以为函数的唯一价值就是“少写重复代码”。这个理解不能说错但把函数想窄了。重复代码只是你肉眼能看到的表象函数真正解决的是把“一段可以独立描述的逻辑”变成一个有名字、可复用、能单独验证的单元。我举个实际例子。你写一个数据处理脚本流程是读文件 → 清洗数据 → 做统计 → 输出结果。如果所有代码都平铺在主流程里头 50 行你还能看清写到 200 行的时候你基本只能靠滚动鼠标去回忆“这一段是干嘛的”。但如果把清洗逻辑封装成clean_data(raw_rows)把统计逻辑封装成compute_stats(clean_rows)主流程就变成四行清晰的调用。代码量没有变少但你的大脑负担小了一个数量级。函数带来的三个核心价值是复用、抽象、可测试。复用是省代码抽象是省脑子可测试是省钱——因为你在生产环境排查 bug 的成本永远比在开发环境跑一个函数高得多。1.2 什么时候该拆函数给有选择困难的人一个标准我知道很多人不是不想写函数是不知道“写到多长该拆”。我用了很多年的一个判断标准分享给你们同一段逻辑出现两次以上且不是一两行就能写完的果断封装。一个代码块干了好几件事比如既读文件又解析格式又做计算拆。你想验证“这段逻辑单独拿出来对不对”那就证明它应该是个函数。一个函数超过 30 行或者嵌套缩进超过 3 层基本就属于“该拆没拆”。这不是什么严苛的代码规范纯粹是经验阈值。30 行是我个人感觉比较舒服的上限超过这个长度你滚动屏幕的次数会明显增加阅读成本也跟着涨。1.3 别让“灵活”变成“失控”Python 很灵活你不写函数也能把程序跑起来甚至能写得很短。但你要想清楚一个问题需求变了怎么办举个例子你原来的价格清洗逻辑是“去掉空值”后来业务方告诉你“空值用中位数填充”。如果你的清洗逻辑散落在代码的 7 个位置你就得去 7 个地方改漏掉任何一处线上数据就错了。封装成clean_price(data)之后你只改一个地方跑一遍测试心里就踏实了。函数不是写给别人看的是写给未来的自己看的。三个月后的你打开这段代码如果一眼能看出来“哦这是清洗价格数据这是计算折扣”那你当初拆函数的时间就没白花。2. def 到 return函数骨架中的关键细节2.1 函数定义和调用比你想的更简单Python 函数的基本形态很简单但有几个点必须刻在脑子里def greet(name): print(fHello, {name}!) return fHello, {name}!行尾的冒号不能丢函数体靠缩进而不是花括号。函数名本质上是一个变量名它绑定到一个函数对象上。你写greet的时候如果你没有加括号你拿到的就是函数对象本身加了括号才是调用它。这个区别会在后面讲回调函数的时候变得特别重要。很多初学者一开始分不清“传函数”和“调函数”其实记住一点就行有括号是执行没括号是引用。2.2 参数传递传的是对象引用不是值副本这是 Python 函数新手踩得最多的坑没有之一。Python 的参数传递方式是“对象引用传递”pass by object reference。什么意思呢你传一个列表进函数在函数里用append修改它外面的列表也会变def add_item(items): items.append(new) return items my_list [old] add_item(my_list) print(my_list) # [old, new]但如果你在函数里写items items [new]这是创建了一个新列表然后让局部变量items指向新对象外面的my_list完全不受影响。很多新人就在这里懵了为什么有时候函数改了变量外面跟着变有时候又不变判断标准只有一个你有没有给变量名重新赋值。调用对象的方法比如append、sort是在修改对象本身不用重新赋值外部可见用重新绑定变量名外部不可见。记住这一条参数传递的坑你就躲掉一大半。2.3 return 的隐藏行为Python 函数如果没有写return或者只写了一个裸return返回值一律是None。这一点看起来简单但会在你写“链式调用”的时候坑你一把。比如你写result print(hello)result是None因为print没有返回值。需要返回多个值的时候直接写return a, bPython 会把它打包成一个元组返回。然后在调用方用x, y func()解包非常方便。另外我强烈建议一件事尽早return。函数开头先做参数校验不满足条件就直接返回不要用三层if嵌套把正常逻辑包在深处。比如def divide(a, b): if b 0: return None return a / b这种写法的可读性比if b ! 0: return a/b else: return None好得多也减少了缩进层级。2.4 作用域全局变量到底该怎么用函数内部读取全局变量不需要任何声明直接读就行。但如果你在函数里给它重新赋值Python 会认为你是在创建一个新的局部变量然后报UnboundLocalErrorcount 0 def add(): count 1 # 报错local variable count referenced before assignment def add_with_global(): global count count 1但你可能会问为什么我在函数里修改一个全局列表的内容不需要globalnumbers [1, 2, 3] def append_number(): numbers.append(4) # 不报错因为append是修改对象本身不是给numbers这个名字重新赋值。你并没有改变“numbers指向哪个对象”只是改变了那个对象的内容。而count 1本质上是count count 1这是重新赋值所以必须声明global。我的个人建议是尽量少用全局变量函数之间通过参数和返回值传递数据代码会清晰很多。全局变量适合做配置常量不适合做可变状态。3. 参数体系位置参数、关键字参数、默认值、*args 与 **kwargs3.1 四种参数类型一次说明白Python 的参数体系比很多语言都灵活这是它的优势也是初学者的迷惑点。我整理了一张表建议你收藏参数类型定义写法调用示例说明位置参数def f(a, b)f(1, 2)按顺序传参最常用关键字参数def f(a, b)f(b2, a1)通过参数名传参顺序可以打乱默认参数def f(a, b10)f(1)调用时不传就用默认值可变位置参数def f(*args)f(1, 2, 3)args收到一个元组可变关键字参数def f(**kwargs)f(nameTom, age18)kwargs收到一个字典调用的时候位置参数必须出现在关键字参数前面。比如f(1, b2)是对的f(a1, 2)直接语法错误。3.2 默认参数的大坑可变对象共享默认参数这个特性Python 初学者十个人里至少有五个踩过这个坑def add_item(item, container[]): container.append(item) return container print(add_item(a)) # [a] print(add_item(b)) # [b] 第二次调用你预期得到[b]实际得到[a, b]。原因很简单默认值是在函数定义时求值一次的同一个列表对象被后续所有没传该参数的调用共享。这不是 bug是设计如此但你很容易踩到。正确的写法是def add_item(item, containerNone): if container is None: container [] container.append(item) return container凡是默认值需要可变对象一律先用None占位函数内部再初始化。这个习惯能帮你避免一大批隐蔽 bug。3.3 *args 和 **kwargs 不只是“收垃圾参数”很多人觉得*args和**kwargs就是“把多余的参数打包收走”这个理解没错但格局太小。它们在真实项目里最大的价值是让你的函数能透传参数。举个例子你要统一封装所有外部接口的调用不同接口的参数不一样def call_api(api_name, *args, **kwargs): print(f调用接口: {api_name}) return api_name _handler(*args, **kwargs)这样不管底层接口签名是什么样的你的统一入口都能接得住。再比如装饰器后面会讲几乎都要靠*args, **kwargs把原函数的参数原封不动地传给包装后的函数。3.4 调用时的解包* 和 ** 的另一面*和**不仅可以用在定义函数时收集参数也可以用在调用函数时展开参数def point(x, y): print(x, y) coords [3, 5] point(*coords) # 等价于 point(3, 5) params {x: 1, y: 2} point(**params) # 等价于 point(x1, y2)你在看一些开源代码的时候经常看到func(*args, **kwargs)意思是“把收到的所有参数原样传给另一个函数”。搞懂了这层看框架源码的时候会轻松很多。4. lambda、闭包与装饰器函数的高级形态4.1 函数是一等公民这是 Python 函数高级特性的根基在 Python 里函数本身就是对象。它可以被赋值给变量可以放进列表、字典可以作为参数传给另一个函数也可以作为返回值从函数里出来。def greet(name): return fHello, {name} say_hello greet print(say_hello(Tom)) # Hello, Tom actions [greet, lambda x: x * 2]“一等公民”这个性质看着抽象但它是一切高级用法的地基。没有这个特性就没有闭包没有装饰器也没有回调函数。4.2 lambda只适合“一行表达式”的场景lambda 是一个单表达式函数适合用在不需要给它起名字的简单场景比如排序的 keyusers [{name: Alice, age: 30}, {name: Bob, age: 25}] users.sort(keylambda u: u[age])写 lambda 的核心原则是如果逻辑超过一行表达式就别硬写成 lambda直接用 def。lambda x: x[1]很清晰但lambda x: x[1] if x[0] 2 else x[1] * 2 1这种东西就纯属给自己找麻烦了。可读性永远比“写得简短”重要。4.3 闭包内层函数带着外层变量的“记忆”闭包是指一个内层函数引用了外层函数作用域里的变量并且在外层函数返回之后这个变量依然被内层函数“记住”。def make_counter(): count 0 def counter(): nonlocal count count 1 return count return counter c1 make_counter() print(c1()) # 1 print(c1()) # 2 c2 make_counter() print(c2()) # 1这里的关键点是nonlocal。你可能会问为什么count 1需要nonlocal因为是重新赋值而count不属于内层函数作用域它属于外层函数make_counter的作用域。如果不写nonlocalcounter里对count的每次访问都只会看到局部的、未被赋值的变量直接报错。闭包的实际用途很多创建带状态的函数、延迟计算、回调函数中保持上下文。比如 GUI 程序里你绑定了好几个按钮事件每个事件处理函数需要知道自己是哪个按钮闭包天然就能帮你把这个信息保存下来。4.4 装饰器不改原函数却给原函数加上新能力装饰器是 Python 函数体系里最“炫酷”的部分。它的本质非常简单一个接收函数作为参数、并返回一个新函数的函数。import time def timer(func): def wrapper(*args, **kwargs): start time.time() result func(*args, **kwargs) print(f{func.__name__} 耗时 {time.time() - start:.4f}s) return result return wrapper timer def slow_job(): time.sleep(1) return donetimer只是slow_job timer(slow_job)的语法糖。加了装饰器之后调用slow_job()实际执行的是wrapperwrapper里先计时再调用原函数然后把数据传回来。装饰器的经典应用场景函数耗时统计、登录权限校验、日志记录、异常捕获、结果缓存。你在 Web 框架里看到的app.route(/)本质上也是一个装饰器只是框架作者把路由注册逻辑封装在里面了。4.5 写装饰器最容易忽略的细节functools.wraps新手最容易忽略的一点是装饰器会把原函数的元信息覆盖掉。你装饰完一个函数再去看func.__name__看到的不是原函数名而是wrapper。这在调试和文档生成时非常痛苦。解决办法是加一行functools.wraps(func)import functools def timer(func): functools.wraps(func) def wrapper(*args, **kwargs): ...这行代码会把原函数的名字、文档字符串、参数签名等信息复制到wrapper上。我自己的习惯是只要写装饰器第一行先写functools.wraps。5. 回调函数与函数式编程在项目里用起来的几种套路5.1 回调函数把动作本身当作参数回调函数的定义很简单把一个函数传给另一个函数让对方在合适的时机调用它。整个过程把“做什么”和“什么时候做”分开了。举一个游戏开发里的例子。你在做 2D 碰撞检测物理引擎负责遍历所有物体、判断是否碰撞但“碰撞之后干什么”是业务逻辑不该写死在引擎里。于是你设计成这样def on_collision(obj_a, obj_b): print(f{obj_a.name} 和 {obj_b.name} 发生了碰撞) collision_system.register_callback(on_collision)引擎在检测到碰撞时调用on_collision而引擎本身完全不关心你到底是播放音效、扣血还是弹出结算界面。这就是回调的解耦能力。Python 里面最隐蔽也最常用的回调其实是sorted和list.sort的key参数。key接收一个函数排序时对每个元素调用它用一个函数告诉你“以什么为基础排序”points [(1, 5), (3, 2), (2, 8)] points.sort(keylambda p: p[0] ** 2 p[1] ** 2)这就是回调只是你用得太熟了没意识到它而已。5.2 函数式风格map、filter 与可读性的权衡map(func, iterable)对序列里的每个元素应用函数filter(predicate, iterable)筛选满足条件的元素它们都是典型的“函数作为参数”的用法。nums [1, 2, 3, 4, 5] squared list(map(lambda x: x ** 2, nums)) evens list(filter(lambda x: x % 2 0, nums))但我想说的是Python 里有比这更可读的写法列表推导式。[x ** 2 for x in nums]和[x for x in nums if x % 2 0]通常比maplambda更直观。我的建议是如果你手上已经有一个现成的函数用map很顺手比如map(str.strip, lines)。如果逻辑需要现写lambda优先考虑列表推导式。filter同理能用if写在推导式里就不要绕一趟lambda。5.3 递归边界、代价与记忆化递归的本质是函数调用自己适合解决树形结构、分治算法这类问题。经典例子斐波那契数列def fib(n): if n 1: return n return fib(n - 1) fib(n - 2)这段代码简洁但性能灾难——fib(40)就开始肉眼可见地卡了因为它重复计算了大量子问题。优化方案是用字典做记忆化from functools import lru_cache lru_cache(maxsizeNone) def fib(n): if n 1: return n return fib(n - 1) fib(n - 2)Python 对递归有两重限制一是默认递归深度约 1000超过会抛RecursionError二是 Python 没有尾递归优化递归层数越高栈开销越大。所以我的建议是能用循环和迭代解决的问题优先不用递归递归只留给那些迭代写起来特别费劲的结构比如树的遍历。练习递归可以试试“李白打酒”这种经典题目但真正写项目代码时递归要谨慎。5.4 yield让函数变成“可暂停”的生成器yield是一种特殊的return。普通函数return之后就把状态全丢掉了而yield会把当前状态保存下来下次next()调用时接着往下执行。def read_chunks(path): with open(path) as f: while True: chunk f.read(8192) if not chunk: break yield chunk这个函数不会一次把整个文件读进内存而是每次只给你 8KB。处理日志、大文本、数据流的时候特别有用。很多做量化交易、大数据处理的人会大量使用生成器因为数据量远超内存时这是最朴素的解决方法。6. 函数设计中的工程实践与性能避坑6.1 命名与单职责函数质量的第一道门槛函数命名我只有一个建议动词开头说清楚干什么。get_user_name、validate_email、parse_config都比handle_data、do_task强得多。名字越具体你维护的时候就越不需要回忆。“单职责”和“命名”其实是同一件事。如果一个函数无法用一句话说清楚它在干什么那大概率它干了两件事。这时候拆开。比如load_and_clean_and_plot这种函数名本身就是重构的信号。6.2 类型注解和 docstring给自己留“使用说明书”Python 3.5 以后支持类型注解配合mypy能做到静态检查很多错误在运行前就能发现def calculate_discount(price: float, rate: float 0.8) - float: 计算折扣价。 Args: price: 原价。 rate: 折扣率默认 0.8。 Returns: 折扣后的价格。 return price * rate如果你的项目是多人协作或者你自己半年后还会回来看这段代码类型注解和 docstring 的价值远超你写它们花的那几分钟。拿量化交易策略打比方get_kline_data(symbol) - pd.DataFrame、calculate_signal(df) - pd.Series、execute_order(qty: int) - str策略逻辑就是一组接口清晰、互相衔接的函数。没有这些签名你的策略代码和在笔记本里涂鸦没有区别。6.3 性能避坑函数内部的三个“慢操作”函数封装不影响性能但函数内部的写法会影响。我常见到三个性能问题第一循环里重复调用昂贵操作。比如在for循环里反复查数据库、反复打开文件应该把能提到循环外的操作全部提前。第二滥用递归。前面已经说过Python 没有尾递归优化深递归就是慢、就是容易爆栈。用迭代改写性能立竿见影。第三全局变量访问慢。函数内部读取局部变量比读取全局变量快这是 Python 的命名空间查找机制决定的。高频率调用的小函数尽量把需要的全局对象通过参数传进去或者做成默认参数缓存。另外一个很容易忽略的优化手段是functools.lru_cache。对于纯函数同样的输入永远得到同样的输出加上它会得到一个无限缓存计算过的结果不再重复算。代价是参数必须可哈希所以它不能装饰“参数是列表”的函数。6.4 给自己写一个“自测入口”比 print 大法靠谱很多初学者调试函数的方式是到处写print跑一遍看输出看完再把print删掉。我强烈建议换成自测入口的写法def calculate_discount(price, rate0.8): return price * rate if __name__ __main__: assert calculate_discount(100) 80 assert calculate_discount(100, 0.5) 50 print(所有测试通过)把测试断言写在文件末尾的if __name__ __main__:块里import这个模块时不执行直接python file.py时才执行。等你的断言越来越丰富你会发现自己排查问题的速度越来越快。我自己在实际项目里最大的体会是函数命名的清晰度和参数的直白程度比写得“高级”重要得多。哪怕只是一个def process(data, modetrain)这样的签名也远比def f(x)好维护十倍。装饰器、闭包这些高级特性确实能写出很漂亮的代码但它们的前提是你对基础函数的调用、作用域、参数传递已经形成了肌肉记忆。顺序不能反地基稳了再上墙否则代码会变成你看着很酷、但一调试就崩溃的空中楼阁。建议你从今天起把手头项目里那些超过 30 行、逻辑混杂的代码块拆出来先封装成清楚简单的函数再一步步往装饰器、生成器这些方向探索。函数这一关过了你往后看推导式、读框架源码、写自动化脚本都会顺畅很多。