哪些开发场景下不建议使用lambda而应优先选择普通函数

以下是Python编码中普遍公认的、应当优先选择def定义普通函数的场景：

1. 函数逻辑需要多次复用的场景 #

• lambda本质是匿名的单行表达式，如果你需要在多处调用同一个逻辑，给普通函数起一个语义化的名字，比到处复制粘贴相同的lambda表达式维护成本低得多。
• 举个例子：你要做数值的平方计算，定义def square(x): return x**2之后可以到处调用，比每次都写lambda x:x**2可读性高很多，后续修改逻辑也只需要改一处。即便是给sorted、map等高阶函数传参数，只要这个逻辑会被多次用到，抽成普通函数也更合理。

2. 逻辑超过单行表达式的场景 #

• Python的lambda严格限制只能写单个表达式，不能包含多语句、多分支（三元表达式除外）、循环、异常处理等逻辑，强行用lambda凑复杂逻辑只会让代码可读性暴跌，甚至根本实现不了。
• 哪怕你能用嵌套三元表达式把多分支逻辑塞进lambda里，写出来的代码也几乎没人能快速读懂，完全违反可读性原则。比如你要写一个先判空、再做类型转换、最后计算的逻辑，用普通函数写多行逻辑清晰易懂，用lambda根本没法正常实现。

3. 需要添加文档说明的场景 #

• 普通函数可以通过docstring添加详细的参数说明、返回值说明、功能描述，复杂逻辑还能加注释，lambda没办法添加标准化的文档说明，后续接手代码的人很难快速理解lambda的作用。尤其是团队协作的场景，无文档的lambda会大幅增加沟通成本和出错概率。

反例示例：你写了一个lambda x,y: (x+y)/2，其他人只能猜这是算平均值的，如果是普通函数可以在docstring里明确说明是计算两个数值的算术平均值，参数要求是数值类型，一目了然。

4. 需要支持递归调用的场景 #

• lambda因为没有绑定的固定函数名，除非你提前把它赋值给一个变量，否则没法实现递归调用，就算赋值后递归，可读性也远不如普通命名函数。比如fact = lambda n: 1 if n <=1 else n*fact(n-1)这种写法非常不直观，而且如果fact变量被重新赋值，递归直接就会报错，远不如普通def定义的阶乘函数稳定。

5. 需要进行测试、调试的场景 #

• 报错栈里lambda只会显示为<lambda>，如果你的代码里有大量lambda，报错的时候你很难快速定位到是哪一个lambda出了问题。而普通函数会直接显示函数名，调试、单测的时候都更容易定位和mock。比如报错TypeError: <lambda>() takes 1 positional argument but 2 were given，如果代码里有十几个lambda，你根本不知道是哪一个出了问题，换成普通函数直接报函数名，定位效率高很多。

6. 需要使用装饰器、或者作为类方法存在的场景 #

• lambda虽然也能加装饰器，但语法非常别扭，远不如普通函数加装饰器的语法清晰。另外如果你要定义类的实例方法、静态方法，用普通def定义的函数是标准写法，用lambda写类方法可读性极差，也不符合PEP8编码规范。

内容的提问来源于stack exchange，提问作者g0x0