Python 经典陷阱深度解析：为什么 `def f(x=[])` 会“记住”上一次调用
Python 经典陷阱深度解析：为什么def f(x=[])会“记住”上一次调用？
在 Python 学习和面试中，有一道题几乎可以称为“照妖镜”：
deff(x=[]):x.append(1)returnx你觉得下面三次调用会输出什么？
print(f())print(f())print(f())很多初学者会直觉地认为结果是：
[1][1][1]因为看起来每次调用f()时，参数x都应该被默认设置为一个新的空列表[]。但真实结果却是：
[1][1,1][1,1,1]这就是 Python 中著名的“可变默认参数陷阱”。
它看似只是一个小坑，实际上背后牵涉到 Python 函数对象、默认参数求值时机、对象引用、可变对象与不可变对象的核心机制。真正理解它，不仅能帮助你避开 bug，还能让你更深入地理解 Python 的运行模型。
一、先说结论：默认参数只在函数定义时计算一次
这段代码的问题核心在于：
deff(x=[]):x.append(1)returnx这里的[]不是在每次调用函数时重新创建，而是在 Python 执行def语句、创建函数对象时就已经创建好了。
也就是说，函数f被定义时，Python 创建了一个列表对象，并把它作为默认参数绑定到函数对象上。之后每次调用f()，如果没有显式传入x，都会复用同一个列表。
可以用一段代码验证：
deff(x=[]):x.append(1)print("x 的 id:",id(x))returnxprint(f())print(f())print(f())你会看到三次输出中的id(x)是一样的，说明它们操作的是同一个列表对象。
这不是 Python 出错了，而是 Python 的设计规则：默认参数表达式在函数定义阶段求值，而不是在函数调用阶段求值。
二、为什么 Python 要这样设计？
有人可能会问：为什么 Python 不让默认参数每次调用都重新计算呢？
原因之一是性能和语义一致性。
看这个例子：
importtimedeflog_time(created_at=time.time()):print(created_at)这里的time.time()也只会在函数定义时执行一次，而不是每次调用都执行一次。
再看：
defconnect(host="localhost",port=3306):pass"localhost"和3306这样的默认值是不可变对象，定义时计算一次完全没有问题，甚至非常自然。
真正容易出问题的是：默认参数是可变对象时。
Python 中常见的可变对象包括：
listdictsetbytearray自定义可变对象常见的不可变对象包括：
intfloatstrtuplefrozensetNonebool所以，下面这些写法一般安全：
defhello(name="Python"):returnf"Hello,{name}"defretry(times=3):returntimes而下面这些写法就要高度警惕：
defadd_item(item,items=[]):items.append(item)returnitemsdefupdate_config(key,value,config={}):config[key]=valuereturnconfigdefcollect(tag,tags=set()):tags.add(tag)returntags三、一步步还原这个陷阱
我们再看原始代码：
deff(x=[]):x.append(1)returnx它大致可以理解为：
_default_x=[]deff(x=_default_x):x.append(1)returnx虽然 Python 内部不是这样直接转换代码的，但这个模型可以帮助理解。
第一次调用：
f()使用默认列表：
[]执行：
x.append(1)变成：
[1]第二次调用：
f()还是使用同一个默认列表。注意，它现在已经不是空列表了，而是：
[1]继续追加：
[1,1]第三次调用继续复用：
[1,1,1]这就是为什么函数像“有记忆”一样，记住了之前的调用结果。
四、用__defaults__看清真相
Python 函数本身也是对象。函数的默认参数保存在函数对象的__defaults__属性中。
deff(x=[]):x.append(1)returnxprint(f.__defaults__)输出类似：
([],)调用一次后：
f()print(f.__defaults__)输出变成：
([1],)再调用一次：
f()print(f.__defaults__)输出：
([1,1],)这非常直观地说明：默认参数中的那个列表确实被修改了。
你也可以直接修改它：
f.__defaults__[0].append(99)print(f())这会输出：
[1,1,99,1]当然，实际项目中不要这么做。这里只是为了理解机制。
五、正确写法：用None作为哨兵值
最常见、最推荐的修复方式是使用None：
deff(x=None):ifxisNone:x=[]x.append(1)returnx现在每次调用f()，如果没有传入参数，都会在函数内部创建一个新的列表。
测试一下：
print(f())print(f())print(f())结果：
[1][1][1]如果显式传入列表，则会修改传入的列表：
data=[10]print(f(data))print(data)输出：
[10,1][10,1]这正是我们通常想要的行为：
没有传参时创建新列表；传入列表时按调用者的意图修改它。
六、为什么不用if not x？
有些人会写成：
deff(x=None):ifnotx:x=[]x.append(1)returnx这段代码看似没问题，但存在隐患。
假设调用者传入一个空列表：
data=[]f(data)因为空列表在布尔判断中为False，所以if not x会成立，函数内部会重新创建一个新列表，导致原本传入的data没有被使用。
正确判断是否使用默认值，应该写：
ifxisNone:x=[]因为None是我们约定的“没有传参”的哨兵值，而空列表、空字典、空字符串可能是调用者有意传入的合法值。
这是一个很重要的工程习惯：判断是否为默认状态，用is None，不要随手写if not x。
七、字典和集合也有同样问题
列表只是最常见的例子，字典和集合也一样危险。
错误写法：
defadd_user(name,users={}):users[name]="active"returnusersprint(add_user("Alice"))print(add_user("Bob"))输出：
{'Alice':'active'}{'Alice':'active','Bob':'active'}正确写法：
defadd_user(name,users=None):ifusersisNone:users={}users[name]="active"returnusers集合也是一样：
defcollect_tag(tag,tags=None):iftagsisNone:tags=set()tags.add(tag)returntags在实际项目中，这种 bug 常出现在配置合并、请求参数收集、缓存临时结果、日志上下文、树结构构建等场景中。它往往不会立刻报错，而是悄悄污染后续调用，等问题暴露时，排查成本已经很高。
八、真实业务案例：接口参数被“串号”了
假设我们写一个函数，用来构造用户查询条件：
defbuild_query(user_id,filters=[]):filters.append(("user_id",user_id))returnfilters调用：
print(build_query(1001))print(build_query(1002))print(build_query(1003))输出：
[('user_id',1001)][('user_id',1001),('user_id',1002)][('user_id',1001),('user_id',1002),('user_id',1003)]这在真实后端服务中非常危险。你本来只是想查询用户 1003，结果查询条件里混入了用户 1001 和 1002。
修复方式：
defbuild_query(user_id,filters=None):iffiltersisNone:filters=[]filters.append(("user_id",user_id))returnfilters更进一步，如果你不希望函数修改外部传入的列表，可以复制一份：
defbuild_query(user_id,filters=None):iffiltersisNone:filters=[]else:filters=list(filters)filters.append(("user_id",user_id))returnfilters这样即使调用者传入已有列表，函数也不会污染原始对象。
九、函数是否应该修改传入对象？
这个问题比默认参数陷阱更深一层。
看下面代码：
defadd_item(item,items):items.append(item)returnitems这个函数会修改调用者传入的列表。它本身不一定错，但要看函数语义是否清晰。
如果函数名叫：
add_item_inplace那么修改原对象是可以接受的，因为名字已经暗示了“原地修改”。
但如果函数名叫：
with_item create_items build_items读者通常会期待它返回一个新对象，而不是悄悄修改旧对象。
更安全的写法是：
defwith_item(item,items=None):ifitemsisNone:items=[]else:items=list(items)items.append(item)returnitems这体现了 Python 编程中的一个重要原则：函数副作用要清晰，不要偷偷改变调用者的数据。
十、在类和数据模型中也要小心
类似问题也会出现在类属性中。
错误示例：
classTaskQueue:tasks=[]defadd(self,task):self.tasks.append(task)测试：
q1=TaskQueue()q2=TaskQueue()q1.add("task A")q2.add("task B")print(q1.tasks)print(q2.tasks)输出：
['task A','task B']['task A','task B']原因是tasks是类属性，被所有实例共享。
更合理的写法是在实例初始化时创建：
classTaskQueue:def__init__(self):self.tasks=[]defadd(self,task):self.tasks.append(task)如果使用dataclasses，也要避免直接写：
fromdataclassesimportdataclass@dataclassclassUser:name:strtags:list=[]正确写法是：
fromdataclassesimportdataclass,field@dataclassclassUser:name:strtags:list=field(default_factory=list)default_factory=list的意思是：每次创建实例时，调用list()生成一个新的列表。
这和函数参数中使用None再创建列表，本质上是同一个思路：不要共享本该独立的可变对象。
十一、什么时候可以故意利用这个特性？
虽然它常被称为“陷阱”，但它并不总是错误。有时我们可以有意识地利用默认参数只初始化一次的特性来保存状态。
例如，一个简单的计数器：
defcounter(state={"count":0}):state["count"]+=1returnstate["count"]print(counter())print(counter())print(counter())输出：
123这确实可以工作，但不推荐在生产代码中这么写，因为它太隐蔽，读代码的人很难第一时间看出你是故意利用共享状态。
更清晰的写法是使用闭包：
defmake_counter():count=0defcounter():nonlocalcount count+=1returncountreturncounter c=make_counter()print(c())print(c())print(c())或者使用类：
classCounter:def__init__(self):self.count=0def__call__(self):self.count+=1returnself.count counter=Counter()print(counter())print(counter())如果是缓存场景，更推荐使用标准库中的functools.lru_cache：
fromfunctoolsimportlru_cache@lru_cache(maxsize=128)deffib(n):ifn<2:returnnreturnfib(n-1)+fib(n-2)print(fib(30))好的工程代码不是不能“炫技”，而是要让意图足够清楚。
当你需要共享状态时，请用更明确的方式表达它，而不是把状态藏在默认参数里。
十二、如何在团队中避免这个坑？
在个人学习阶段，知道这个知识点就够了；但在团队协作中，还需要制度化地避免它。
1. 代码评审中重点检查函数签名
看到下面写法要立刻警觉：
deffunc(a=[]):passdeffunc(config={}):passdeffunc(options=set()):pass除非作者能明确说明这是故意设计，否则都应该改掉。
2. 使用类型标注提升可读性
推荐写法：
fromtypingimportOptionaldefadd_item(item:int,items:Optional[list[int]]=None)->list[int]:ifitemsisNone:items=[]items.append(item)returnitems在 Python 3.10 及以上，也可以写得更简洁：
defadd_item(item:int,items:list[int]|None=None)->list[int]:ifitemsisNone:items=[]items.append(item)returnitems类型标注不能自动解决这个 bug，但它能让函数意图更清晰，也能帮助编辑器和静态检查工具发现问题。
3. 配合测试覆盖边界行为
针对这种问题，单次调用测试可能无法暴露 bug。
错误函数：
defadd_item(item,items=[]):items.append(item)returnitems如果只测一次：
deftest_add_item_once():assertadd_item(1)==[1]测试会通过。
但应该增加连续调用测试：
deftest_add_item_multiple_calls():assertadd_item(1)==[1]assertadd_item(2)==[2]这样才能发现第二次调用被污染了。
4. 使用静态检查工具
很多代码检查工具都能发现“可变默认参数”问题。团队可以在提交代码前运行格式化、静态检查和单元测试，将这类问题挡在合并之前。
一个健康的 Python 项目，通常至少应该有：
格式化工具 静态检查 类型检查 单元测试 持续集成工具不是为了束缚开发者，而是为了让团队少在低级错误上浪费生命。
十三、一个可操作的排查清单
如果你怀疑项目中存在类似问题，可以按下面步骤排查。
第一步，搜索函数默认参数中的可变对象：
=[] ={} =set() =list() =dict()第二步，检查类属性中是否定义了可变对象：
classA:data=[]第三步，检查数据类或配置类中是否直接使用了可变默认值。
第四步，检查函数是否会修改传入参数，比如：
append extend insert remove pop clear update setdefault add第五步，为相关函数补充连续调用测试，确保多次调用之间不会互相污染。
这个排查过程非常适合用在老项目重构中。你会惊讶地发现，很多“偶现 bug”“脏数据”“状态串扰”都和共享可变对象有关。
十四、把这个陷阱讲给初学者听
如果要用一句话解释这个问题，可以这样说：
Python 的函数默认参数不是每次调用都新建的，而是在定义函数时创建一次；如果默认值是列表、字典、集合这种可变对象，后续调用会共享它，所以修改会被保留下来。
如果用生活化比喻，可以这样讲：
默认参数中的[]不是“每次入住都换新的酒店房间”，而是“所有没带房间号的人都住进同一个房间”。你第一次往房间里放了一把椅子，第二个人进来时椅子还在；第三个人再放一把，房间里的东西就越来越多。
而None写法相当于：
deff(x=None):ifxisNone:x=[]每次没有指定房间时，前台都会重新开一间新房。这样每位客人的东西就不会混在一起。
十五、最终建议：记住这三条就够了
第一，不要把可变对象作为函数默认参数。
避免：
deff(x=[]):passdeff(config={}):passdeff(tags=set()):pass第二，使用None作为默认值，并在函数内部创建对象。
推荐：
deff(x=None):ifxisNone:x=[]returnx第三，如果函数会修改传入对象，要在命名、文档或实现上明确表达。
例如：
defappend_item_inplace(items,item):items.append(item)或者选择不修改原对象：
defappended_item(items,item):new_items=list(items)new_items.append(item)returnnew_items结语：真正的 Python 功力，藏在这些“小地方”
def f(x=[])这个问题之所以经典，不是因为它难，而是因为它连接了 Python 中很多关键概念：函数对象、默认参数、引用语义、可变对象、副作用、测试和工程规范。
很多人学习 Python，是从“语法简单”开始喜欢它的；但真正写久了会发现，Python 的魅力不只是简洁，而是它鼓励你写出清晰、直接、可表达意图的代码。
一个成熟的 Python 开发者，并不是从不犯错，而是知道哪些地方容易出错，并能用习惯、工具和测试把风险提前消化掉。
所以，下次看到这段代码：
deff(x=[]):x.append(1)returnx你不只是知道它会输出：
[1][1,1][1,1,1]更应该知道它为什么这样、如何修复、如何在团队项目中避免、以及什么时候应该用更清晰的方式表达状态。
这就是从“会写 Python”走向“写好 Python”的关键一步。
你在项目中是否遇到过类似的“状态串扰”问题？是默认参数、类属性，还是缓存设计导致的？欢迎在评论区分享你的排查经历和解决方案。也许你的一个案例，就能帮另一位开发者少熬一个夜。