别再掉坑了！这个Python细节坑了无数人（含救命写法）

Python 函数会“记仇”？一个默认参数把两个用户的数据拧在了一起

你学 Python的时候有没有碰到过这种灵异现场：明明第一次调用结果很对，第二次却“变脸”了，明明没动代码，数据却溢到了别人那儿？我记得那次线上故障，接口返回的数据像被搅拌机搅过一样，A用户查 apple，B 用户查banana，结果大家都能看到对方的东西。我们翻了半天日志，最后罪魁祸首竟然是一个看似无害的函数默认参数，一个空列表在函数定义那一刻被创造出来，然后一而再再而三地被复用，结果状态像借宿一样被传染开来。

背后的真相比你想的简单也更残酷：函数的默认参数在定义时就评估一次，那个空列表并不会每次调用都重建。换句话说，你不是在每次给函数塞一个新的杯子，而是在每次让别人共喝同一个杯子。如果你把可变对象当默认值放进去，列如list、dict、set，这个杯子会被前一次的内容污染下一次的结果；如果你放的是不可变对象，列如数字或字符串，那么就没问题，由于它们本身不会被改写。

许多人看到这里第一反应是“这设计也太坑了”，说实话我也能理解这种愤怒。但这实则是语言设计的一部分，是“万物皆对象”的副产物。Python把默认参数当对象引用来处理，这在性能上对不可变对象还挺友善，但对可变对象就风险很大。真正的误区不在语言，而在“想当然”——以为默认值每次都会重建，这种假设一旦落到生产环境，代价往往很高。

遇到问题该怎么办？一个简洁且安全的模式是用 None作为哨兵。也就是把默认参数写成 None，然后在函数体内判断，如果是 None就创建一个新的列表。这样每次调用都会得到独立的容器，状态不会意外泄露。把这件事当成编程习惯，我身边的同事小李就是这样改过后再也没由于共享状态被叫到半夜上线去补救。对于dataclass 场景，使用 default_factory可以实现同样效果而且语义更清晰。

当然，这里也有争议的角落。有些人会故意利用默认可变对象来做轻量级缓存，把状态复用当作特性来用，这在单线程脚本里可能看着机智，但在并发的Web服务里就超级危险，尤其是没有加锁或没有思考进程模型的时候。我的经验是，如果你的默认值是为了缓存，写明注释并且加上线程/进程安全的机制，或者干脆把缓存交给专门的缓存层，这样既不“偷懒”也不埋隐患。

除了 None 哨兵和default_factory，还有一些细节值得注意。像类属性如果定义为可变对象，所有实例也会共享这份状态；闭包里引用的可变对象也可能造成意想不到的跨调用影响。写代码时多问一句“我希望这个容器是每次独立的吗”，往往能提前避免许多排查痛苦。我自己目前习惯在函数签名附近写一句短注释，说明默认参数的语义，这样团队新人看代码不会误解。

最后，说点容易记住的话：不要让默认参数去记仇。代码不会凭空捣乱，它只是忠实地执行了你没看懂的规则。理解这些底层机制，能把许多“随机性”变成可控的行为。写得久了你会发现，能少踩坑比能写复杂逻辑更重大——少踩一次坑，等于省下一次大半夜的心慌。

你有没有被默认参数坑过？或者在生产里由于共享状态吃过教训，来讲讲你的故事和你是怎么修复的，说说你当时的排查思路和最终的解决办法吧。