脸书差点把我的电脑搞报废

今天聊点让人不舒服的事：大厂也会写出烂代码，这事儿真不是传说。

有个开发者分享了一段经历，听起来像编的，但确确实实发生了。他的浏览器打开 Facebook 首页，就那么放着，什么都不动，结果内存一路狂飙，直接触发了 Linux 的 earlyoom 内存保护机制，浏览器就这么崩了。

页面加载了 facebook.com/?_rdr，显示一个转圈的 logo，然后就开始像漏水一样疯狂吃内存。那速度，任何初级开发者看了都得脸红。16G 内存被吃掉 15.3G，整个系统都快被榨干了。Swap 分区也占了一半。最后系统实在看不下去，直接把这个进程给终止了，不杀它整台电脑就得挂。

看着系统监视器上那条内存曲线一路攀升、攀升、再攀升，然后突然断崖式下跌——这就是你的操作系统在说："总得有个程序去死，其他程序才能活。"

脸书？你在逗我？

这事最离谱的地方在哪？不是哪个小工作室的试验田，也不是哪个穷得叮当响的创业公司。这是 Facebook。 是定义了现代 Web 架构的那家公司，是养着成千上万工程师的公司，是每天处理几十亿请求的公司。一个能漏掉好几 G 内存的重定向循环，这种 bug 在 QA 第一周就该被发现。

时机也很有意思。最近 Meta 可没少上头条，到处抽调工程师去搞 AI。训练模型、打标签、建测试集——听着挺高大上的。但以前谁在做那些"无聊的活儿"？基础设施工程师、性能优化工程师、那些确保首页不会把你的内存当零食吃掉的人。

把这些人都调走了，结果就是：旗舰产品首页连自己都加载不明白。

对开发者和企业意味着什么

这事值得每个搞技术的人好好想想。有几点启示：

1. 性能优化不是可选项

不管你是社交媒体巨头还是个小型企业网站，资源管理都不能马虎。你的程序多吃一兆内存，其他程序就少一兆。规模大了，这些小问题会累积成大灾难。

2. 核心基础设施要持续投入

追新功能、蹭 AI 热点确实很诱人。但维护、优化、测试现有系统这些"不酷"的活儿，才是让一切正常运转的关键。忽视它，早晚出事。

3. 内存泄漏是隐形杀手

跟那些报错信息明显的 bug 不同，内存泄漏在开发阶段经常神不知鬼不觉。测试环境跑得好好的，放到生产环境就开始慢慢蚕食内存。这才要命。所以监控、自动测试、合理设置资源限制，一个都不能少。

说到 Hosting

在 NameOcean，我们天天见到资源管理不善的后果。不管是配置错误的程序把 RAM 吃干抹净，还是某个吃资源的网站把整个共享服务器拖垮，道理都是相通的：

• 监控你的程序。 earlyoom 这类工具存在是有道理的，系统需要保护，免得被失控的进程拖下水。
• 设置合理的资源限制。 容器化、做好隔离，确保一个出问题的程序不会把整个基础设施搞瘫。
• 选能看清楚的 Hosting。 VPS 和独服方案自带系统监控，能让你在内存问题爆发之前就发现苗头。

大局来看

这事儿说起来还有点讽刺。大家都在追 AI 热潮，公司可能正在忽视支撑现代 Web 的那些基础技术。花在训练大语言模型上的每一块钱，都是没花在确保网站高效加载、节约资源、不把用户电脑搞崩上的钱。

对于创业者和开发者来说，这反而是个机会。当大厂都在做 AI 梦的时候，那些懂性能优化、懂资源管理、写得出干净代码的人，才是能做出靠谱应用的人。

说到底挺讽刺的：Facebook，这家在 2000 和 2010 年代定义了 Web 性能标准的公司，现在居然连自家首页的内存泄漏都管不住。说不定整个行业该集体回归基础了——不管技术发展到什么程度，硬件资源的硬约束是躲不掉的。

Meta，你们要是能看到这篇文章：把工程师们调回来吧。还有人要登录呢。

你对大规模 Web 性能现状怎么看？有没有遇到过类似"吃内存"的网站？评论区聊聊你的经历。