昨天帮人看一段小脚本，发现个挺隐蔽的bug。嗯函数大概长这样：def add_item(x, lst=[]): lst.append(x); return lst。作者本意是每次不传lst就新建一个空列表，结果跑起来才发现，多次调用之间那个列表一直在累积。第一次add_item(1)返回[1]，第二次add_item(2)居然返回[1,2]。

后来才想明白，Python的默认参数不是在每次调用时求值的，而是在函数定义那一刻就求值一次，之后所有调用共享同一个对象。列表、字典这类可变的，就会在调用间被悄悄复用。这个直觉之外的点，刚写Python的人特别容易踩。

我现在习惯用None当哨兵值，函数体里再判空初始化：如果lst是None就新建一个。写法啰嗦一点点，但不会再出这种鬼问题。新人阶段大概率都栽过一次，栽过就记住了（笑）

我年轻那会儿第一次撞上这玩意儿，对着屏幕愣了半天。

当时还以为是自己作用域没整明白，翻来翻去，最后在函数对象的 defaults 里看见安安静静躺着同一个 list。那一刻真是拍大腿。

楼主说的 None 哨兵是最稳的，我后来也一直这么写。不过这"共享默认对象"的脾气，偶尔也能废物利用。早年没 lru_cache 的时候，有人拿它当简易缓存，在函数里挂个可变对象，跨调用留点状态。现在当然不这么折腾了。
那会儿
栽过一次，基本这辈子都忘不掉。

这坑我也踩过，盯着那个越变越长的列表愣了半天，lst偷偷攒家底可太形象了

这种悄悄累积的感觉，总让人心里发毛。你以为每次推门进去都是一间空房子，其实门后那张桌子从第一次起就没空过，前面的人落下的东西，安静地等着后来的人去撞见。坦白讲

我也栽过一回，当时还纳闷输出怎么越跑越长。后来才懂，Python是在函数定义那一刻就把那个列表实实在在地造出来了，之后每次调用都奔着同一个物件去。用None当哨兵确实最省心，进了门再决定要不要重新铺一张干净的桌子。
坦白讲
栽过的人，大约都记得那张桌子原来一直在。

深夜读你这段，莫名想起自己头回撞上这个坑的午后。坦白讲那时也是写个小脚本，list 在两次调用之间越攒越长，我愣是盯着屏幕发了好一会儿呆——分明每次都当是崭新的开始，怎么兜里却一直装着上次的残渣。我觉得吧

你说的「定义那一刻就求值一次」真戳到点子上。我们总习惯把函数的每次召唤想成一张白纸，Python 却偏在暗处把它们系在同一条线上。这种静默的复用最磨人，不报错也不警告，只是温柔地、一点点把东西堆起来，像窗台上不知何时积起的灰。

后来我也改成 None 作哨兵，写法啰嗦些，心里却踏实。只是偶尔会想，这世上好多事怕也类似：我们以为翻了篇，那页却还虚掩着，前一次的痕迹照样被下一次读走。新人栽一次就记住，记忆多半是这么长出来的。

你们天天和这种「看不见的共享」打交道，怕是比旁人更早懂得：原来看似干净的「重新开始」，从来不是 default 值。

读到那个"定义那一刻就求值一次"的说法，忽然像站在旧院子的一口井边。头回凿开之后，后来的每次打水都在同一汪里添东西…，水面就这么不知不觉浑了。我自己早些年也在这坑里跌过一跤，当时只当脚本脾气古怪，如今回头看，原是它把"头一次"记得太牢，舍不得换。

年轻那会儿写脚本可没现在这些讲究，头回撞上这毛病时，还当是自己逻辑写岔了，对着那串越攒越长的列表发了好一会儿呆。

后来才弄明白，是解释器在函数定义那一刻就把那个空列表给备好了，往后每次调用都拎同一个出来用。怎么说呢可变对象做默认值这事儿，确实挺反直觉。我现在也跟你一样用 None 当哨兵，多写一行，图个心安。怎么说呢

新人栽这么一回真不算坏事，记性比光翻文档牢多了。

我年轻的时候也在这上面栽过跟头。那时候图省事，写了个缓存函数，默认参数塞了个空字典进去，结果跑了小半个月才发现所有请求都堆到同一个对象里去了，排查那几天差点把头发薅光。我觉得吧

后来才想明白，Python 是把默认参数当成函数定义的一部分，定义那一刻就求值一次、之后一直复用。现在我用 None 当哨兵都成肌肉记忆了，新写的代码基本不会再踩。

不过话说回来，这种坑只要栽过一次，以后看见谁写 lst=[] 都会下意识皱下眉，也算长记性了。

我也被这个坑过，debug半天以为是自己变量名写串了，结果是默认参数在背刺我hh

关于"共享同一个对象"这个说法，可以再抠一下。准确讲，坑不在于默认参数被共享，而在于它被原地修改了。你那个例子里真正的罪魁是 lst.append(x) 这个 in-place 操作。如果把函数改成 return lst + [x]，哪怕默认还是 []，多次调用也不会累积——因为 + 生成的是全新的对象，原来的默认列表从头到尾没被动过。所以更精确的判断标准应该是：默认值是可变的，且函数体里对它做了原地变更，__defaults__ 里挂的那个对象才会被污染。

顺带可以用 add_item.__defaults__ 验证，返回的是 ([],)，也就是被反复 append 的同一个 list 的引用。想看它长胖没有，调用前后打印一下 __defaults__[0] 就知道了，比在外部猜直观得多。

None 哨兵那个写法我也在用，不过有个小坑值得补一句：别图省事写成 lst = lst or []。调用方传了空列表 [] 时两种写法结果一样，但如果这个参数将来可能合法接收 0、'' 这类值，or 会把它吞掉换成新的空列表，语义就偏了。严格等价于"没传"的只有 if lst is None。
其实
还有一种更讲究的写法，当 None 本身也是合法输入时：自定义一个 MISSING = object() 当默认值，函数体里 if lst is MISSING。这样"没传"和"传了 None"就能区分开，不会被混为一谈。

这个行为其实不是 bug，是 CPython 故意这么设计的，官方文档里写得明明白白。从某种角度看，它能让默认参数捕获函数定义那一刻的 context，比如 def log(msg, t=time.time())，只不过大多数时候我们并不想让它这么干。

读到你说"列表一直在累积"那句，忽然觉得这像极了生活里某些怎么都清不掉的东西。你以为每次推门进的都是一间新屋子，结果桌角还搁着上回没带走的那杯凉茶，杯底的水痕清清楚楚写着昨晚的事。

Python 这家伙也够执拗的，默认参数在函数降生那一刻就定下了，此后每一次呼唤都指向同一个去处。嗯…新人栽跟头，多半是拿人的心思去揣摩机器的记性，总以为不传参便是重新来过。其实它从不替你抹去什么，只管把旧的接着用下去。

我早先也在这上头绊过，有回夜里跑脚本，第二天醒来满屏都是串了味的结果，才老老实实改用哨兵值。有一说一这种教训大约都这样，旁人说得再轻巧，终究要自己跌那一跤才真记住。就像哪首老歌里唱的，以为忘了，其实都还在。

这坑我当年也踩过。有回写个小脚本，默认参数直接塞了个空列表，跑起来一切正常——直到某天发现输出里混进了好几天前的旧数据，像是有什么东西在背后默默记着账。查到原因那一刻，后背有点凉。

后来我就老实了，可变对象一律 None 顶着，多写两行换来睡得安稳。其实 lint 工具早就会提醒这个，只是人总要先挨一下才肯听劝。

第一次撞上这事儿的人，大多要愣好一会儿，“它怎么可能这么干”。