一个Python的列表参数是如何搞垮一个网站的

废话少说，先看代码

def add_end(L=[]):
    L.append('END')
    return L

这段python代码看起来有什么问题吗？看起来是不是也没啥问题，L是个入参，list形式的，不传的话有个空list作为默认值，业务体里面对L进行了内容追加，并把追加后的L对象返回。业务很简单

但就是这样的一个看起来人畜无害的代码让一个网站在痛苦中度过了一个月的时间，同时流失了大量的用户，让我们来看一下亲历者回忆当时的情况吧

Digg's v4 launch: an optimism born of necessity.

不想看英文的同学可以全文翻译或者看下面节选的关键内容：

背景：digg是一个以科技为主的新闻站点，用户可提交新闻予digg，通过digg机制显示于digg首页上。十几年前web2.0的弄潮儿，巅峰时期月访问量在3000W以上，于12年没落，至今依然保持运营。这个事情发生在18年，让这个本不富裕的网站雪上加霜

18年Digg到推出V4，从V3.5到V4已经持续开发了两年时间，整个公司希望通过V4让Digg重回互联网第一梯队。他们甚至提前准备了庆祝的香槟（半场开香槟，传统艺能了）

他们准备了升级的方案，但没有回滚计划（这flag立的，铭记墨菲定律）

升级之后的网站并没有按计划展现，而是因为后台的高负载导致大多数页面都无法加载。中途Digg团队观察到了数据库（Cassandra）和缓存（memcache）负载高，扩容了一次，但还是没有彻底解决问题。特别是V4中最重要的MyNews页面，这是这个版本中最亮眼的功能，以及用户的默认页面，然而这个页面却一直都在报错

Digg团队后来把初始页面改成了TopNews，来保证用户不至于在登录的时候就看到错误页面，但问题还是没有得到解决

两天后Digg团队把数据从Cassandra迁移到了redis中，提升了数据库的访问性能。问题得到了缓解，但还是需要每隔4小时重启一次服务

一个月后，问题终于被查出来了，Digg的API服务是一个Python服务，类似于网关层，作为网关需要查询用户信息，这个用户信息的查询函数的参数形式就是上面这种列表形式（当然具体代码长啥样子咱也不知道，只知道形式），就是这样的代码形式导致了这一个月的问题

OK，让我们执行一次上面的函数

>>> add_end()
['END']

看着没问题哈，再执行个带参数的

>>> add_end([1, 2, 3])
[1, 2, 3, 'END']

看着也没问题哈，让我们再执行一次无参的

>>> add_end()
['END', 'END']
>>> add_end()
['END', 'END', 'END']

嗯？为什么会这样？默认参数是[]，但是函数似乎每次都“记住了”上次添加了'END'后的list

原因解释如下：

Python函数在定义的时候，默认参数L的值就被计算出来了，即[]，因为默认参数L也是一个变量，它指向对象[]，每次调用该函数，如果改变了L的内容，则下次调用时，默认参数的内容就变了，不再是函数定义时的[]了

因此在大量用户访问Digg的时候，L中的默认列表会越来越大，而且伴随着并发访问，这是一个二次以上多项式级别的增长，很快就会吃满内存，导致服务不可用

代码和解释参考，里面也讲了如何解决：廖雪峰：函数的参数

这样的问题的确很隐蔽，甚至有的时候反直觉（可能是对于不熟悉的人来说），这时候熟练使用一些静态代码检查的工具就显得尤为必要。这些别人已经踩过的坑很多已经总结在了这些工具里，即使他无法确定这一定是个BUG，也会给研发人员一些危险编码方式的提示。