那次 faker.js 干掉了我的测试环境——用开源6年，踩过的6个真实大坑

---

2022年1月9号，周一早上九点，我打开电脑准备发版。Jenkins上的构建任务红了一大片。点进去看，错误全指向 faker.js——我们项目里所有生成的假数据都变成了 undefined。

我第一反应是缓存问题。清缓存，重新安装依赖，没用。去GitHub一看，代码没了。作者把整个仓库清空了，commit message写的是：

“End of maintenance. I’m not going to continue providing free labor.”

faker.js 和 colors.js，两个加起来周下载量超过2000万的包，一夜之间废了。

那天我在工位上坐了十分钟，在想一个问题：我们每天 npm install 的那几百个包，背后到底是谁在维护？如果他们明天全都不干了，会怎样？

这个问题困扰了我很久。后来我想明白了——与其担心，不如聊聊我这些年用开源项目踩过的坑。有些是真的想骂，有些是真觉得好用到想安利，还有些是又爱又恨。

---

一、Webpack：每个前端都骂过，但没人敢从简历上删掉

用了4年 | 64k+ Star | 配置文件最长见过700行

我第一次接触Webpack是2019年。当时刚转前端，带我的师兄甩过来一个webpack.config.js，说"你先看看"。

我看了两个小时。loader和plugin的区别搞明白了，但为什么babel-loader要配在rules数组里，而html-webpack-plugin要写在plugins数组里？没人给我解释。文档里有说，但藏在第17层链接下面，而且示例代码用的还是两个版本前的语法。

后来每次Webpack大版本升级，我都得重学一遍。Webpack 4的时候我搞懂了SplitChunks，到了Webpack 5又改了配置方式。tree shaking的原理我看了三篇文章才搞明白，最后发现实际项目里效果并不明显——因为团队里总有人在代码里写 import _ from 'lodash'。

有一次我花一下午优化构建速度。照着官方文档的"性能优化指南"逐条改：开启持久化缓存、调整splitChunks、配置thread-loader…改完一跑，构建时间从3分钟变成了3分20秒。

我差点把键盘摔了。最后发现是缓存配置的目录没权限，Webpack在反复报错重试。修好之后变成1分40秒。但也说不清到底哪一步起的作用。

你问我为什么不用Vite？ 用过。新项目能用Vite的我都用Vite。但有些老项目依赖链太深，迁移成本太高。还有些场景——比如需要精细控制代码分割策略、或者要用到某些只有Webpack插件的构建功能——Vite暂时替代不了。

所以Webpack就是那种典型的"又恨又离不开"的项目。

安利指数：⭐⭐⭐ | 吐槽指数：⭐⭐⭐⭐⭐

---

二、faker.js：一个开发者的崩溃，整个社区的警钟

事件：2022年1月 | 当时42k Star | 现已由社区接手维护

回到文章开头那个周一。

后来的事大家都知道：GitHub介入，从历史记录恢复了代码，社区组建了8人维护团队接手 faker.js。原作者Marak Squires被"出局"了——一个维护了多年的项目，以这种方式和自己告别。

很多人骂Marak不负责任。确实，删库影响了几千个项目的构建。但换个角度想：faker.js的周下载量是千万级别的，有多少用户给过他哪怕一块钱？GitHub Sponsors上他的赞助者数量，我忘了具体数字，但肯定远远低于下载量。

他在issue里写过一段话，大意是：“我让一家公司每年省下了无数开发时间，但我自己连房租都快交不起了。”

这件事之后我做了两件事：第一，把我们项目里的核心依赖全部lock了版本；第二，给几个常用的开源项目点了Star。

但说实话，最让我不安的不是某个包可能消失，而是——整个前端生态的稳定性，建立在无数个免费劳动的基础之上。 这个模式本身就很脆弱。

---

三、left-pad：11行代码，一晚上搞瘫了Babel和React

事件：2016年3月 | 功能：字符串左侧填充 | 代码量：11行

这个事虽然已经过去十年了，但我觉得每个程序员都应该知道。

Azer是一个开发者，他在NPM上发了一个叫kik的包。Kik Interactive公司想要这个名字，发律师函让他让出来。NPM的CEO在没有通知Azer的情况下，直接把包的权限转给了Kik公司。

Azer很生气，把自己发布的所有包都从NPM上撤了。其中一个叫left-pad。

left-pad的功能就是字符串左侧补零/补空格。11行代码。但Babel、React、数千个包都间接依赖它。Azer一撤，硅谷到处飘红的构建错误。NPM紧急开会，最后破例强制恢复了left-pad。

这件事之后NPM改了策略——如果你发布的包超过24小时，或者一周内下载量超过一定阈值，就不允许unpublish了。

但问题真的解决了吗？你打开自己项目的package.json，看看间接依赖了多少个包。node_modules里的文件数量通常是直接依赖的几十倍。这里面有多少个"11行代码"的包？它们的维护者还在吗？心情好吗？

我不知道。你可能也不知道。

---

四、Redis：从"开源标配"到"你交钱才能用"

事件：2024年3月 | 68k+ Star | BSD → SSPL

Redis的许可证变更，是2024年开源圈最大的事件之一。

2024年3月21号，Redis公司宣布许可证从BSD变为SSPL。理由是AWS在卖Redis托管服务赚大钱，但给Redis项目的贡献很少。

这个理由我能理解。但问题是，AWS是AWS，我是我。我们一个十几个人的小团队，用Redis当缓存，也没赚什么大钱。你一纸公告把许可证改了，我们怎么办？法务要重新审核，技术要评估风险，管理层要开会讨论。这些都是时间。

后来社区搞出了Valkey——一个完全开源的Redis分支。Linux基金会背书，AWS、Google、Oracle都参与了。Valkey的Star数增长很快，目前已经有60k+。

我去年把一个项目从Redis迁移到Valkey。API兼容，性能没有明显差异，迁移过程大概花了半天。但如果你用了Redis的某些高级特性（比如RediSearch、RedisJSON），迁移就没那么简单了。

Redis公司赌的是品牌认知度够强。从目前看，Valkey正在逐步蚕食Redis的市场。在开源世界里，没什么东西是不可替代的。

安利指数：⭐⭐⭐⭐（推荐用Valkey） | 吐槽指数：⭐⭐⭐⭐

---

五、MinIO：59K Star，说不维护就不维护了

事件：2025年12月 | 59k+ Star | Go语言

这个事就发生在半年前，热度没那么高，但对我触动很大。

MinIO是高性能分布式对象存储，很多公司用它搭建私有云存储，替代AWS S3。API兼容S3，部署简单，性能确实不错。2025年12月3号，MinIO官方宣布进入维护模式：不再接受新功能和新PR，只做关键bug修复。

公告很短。就那么几句话。

59K Star的项目。很多企业的存储架构都搭在上面。说停就停。

后来有分析说，MinIO公司的商业重心在转向企业版（MinIO Enterprise），开源版维护的优先级降低了。这也是可以理解的——公司要赚钱，不可能永远免费。但从使用者角度来说，这就是一个活生生的案例：你以为选了一个Star数很高、社区活跃的项目就安全了，但维护者的商业决策随时可能改变。

我后来在项目选型时多加了一个评估维度：这个项目的维护主体是个人、社区还是公司？如果是公司，它的商业模式是什么？开源版和商业版的关系是什么？

这些事以前我不关心。MinIO之后我开始关心了。

安利指数：⭐⭐⭐ | 吐槽指数：⭐⭐⭐

---

六、Axios：最常用的HTTP库，也是最让人抓狂的

如果你不做前端、也不用Node.js写后端，这节可以跳过。

用了5年 | 105k+ Star | 周下载量5000万+

Axios可能是前端和Node.js开发者用得最多的HTTP库了。每个项目都用它。但它有几个设计问题让我一直很烦。

取消请求的API改了两三次。 早期用CancelToken，一个奇怪的构造函数用法。后来换成了AbortController，跟浏览器原生API对齐了。但中间过渡期，网上的教程一半教你CancelToken，一半教你AbortController。我接过一个项目，代码里三种取消写法并存，每个是不同时期的同事写的。我光是统一风格就花了半天。

错误处理逻辑不统一。 有些API后端设计不规范，200返回错误信息（放在body里），404反而返回正常提示。Axios的拦截器默认2xx走成功回调、非2xx走error回调，遇到这种不规范API你得手动改判断逻辑。写得丑不丑另说，关键是容易出bug。

isCancel这个函数的设计。 这是Axios内部判断错误是否来自取消请求的工具函数。名字叫isCancel，但检查的是error.__CANCEL__这个内部属性，不是标准接口。你得额外import一下才能用。而且这个名字跟Axios其他API的命名风格对不上。

我有时候在想，Axios这么常用，为什么不干脆出一个"v2大版本"，把历史包袱全部扔掉重新设计？但转念一想——5000万的周下载量，任何一个breaking change都会引发海量的issue。它已经被自己的成功绑架了。

当然，Axios还是比原生fetch好用。 fetch不支持拦截器，不支持超时，不会自动JSON解析，404和500不进catch。每次用fetch我都要写一堆样板代码。Axios虽然有不少设计问题，但开箱即用的体验确实好。

安利指数：⭐⭐⭐⭐ | 吐槽指数：⭐⭐⭐

---

选开源项目，我现在的判断标准变了

以前我选开源项目，只看两个东西：Star数和ReadMe写得漂亮不。

faker.js事件之后，我在每个项目的GitHub主页多看了几眼：最后一次commit是什么时候？维护者有几位？issue的平均响应时间几天？有没有公司在背后支持？有企业版吗？

这套判断标准帮我躲过一些坑了。去年评估一个日志采集组件的时候，发现核心维护者只剩一个人，最后一次commit是半年前。最后选了另一个Star少但背后有两家公司共同维护的替代品。

这不代表只能选大厂背景的项目。但把一个核心依赖放在一个随时可能跑路的个人项目上，这事儿得想清楚。

最后问一句：你用的开源项目里，哪个让你崩溃过？或者哪个你觉得真的被低估了？评论区聊聊。

---

本文仅代表个人使用体验，不构成任何技术选型建议。数据来源于GitHub公开信息，如有出入以官方为准。

---

#开源项目吐槽大会 #前端开发 #开源生态 #程序员日常 #技术选型