程序员奉为圭臬的信条之一是“不要重复造轮子”。然而，如同软件开发中的许多绝对性断言一样，实际情况远比这复杂。本文将探讨引入看似便捷的npm包时，其成本可能远高于自行编写代码的情况。
免费代码的陷阱
我们都经历过：需要实现某个功能，恰好有一个npm包能完美胜任。它很流行，维护良好，只需
npm install即可搞定。但事情并非总是如此简单。
// 一个简单的日期格式化器，对吧？
npm install moment
// 代码中后续部分...
import moment from 'moment' // 捆绑包增加231kb
const formattedDate = moment(date).format('mmmm do yyyy');
// 自己编写代码
const formatDate = (date) => new Date(date).toLocaleDateString('en-US', {
month: 'long',
day: 'numeric',
year: 'numeric'
}); // 约300字节
仅仅是无意中引入了一个包，就增加了231kb的捆绑包大小。相比之下，整个jQuery库大约只有87kb。
实际成本
- 捆绑包大小膨胀
让我们来看一个现实案例，看看依赖项是如何层层累积的：
// 需要一个简单的深拷贝功能 npm install lodash // 531kb // 使用原生方法 const clone = obj => structuredClone(obj); // 需要验证邮箱地址 npm install validator // 364kb // 使用简单的正则表达式 const isValidEmail = email => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
每个库都会增加捆绑包大小，从而增加加载时间，并可能影响用户体验。 2. 安全漏洞
还记得left-pad吗？这个臭名昭著的11行代码包曾瘫痪了半个互联网。它的代码如下：
// 完整的left-pad包代码
function leftPad(str, len, ch = ' ') {
str = String(str);
let i = -1;
len = len - str.length;
while (++i < len) str = ch + str;
return str.padStart(len, ch);
}
每个依赖项都是潜在的安全隐患。依赖项越多，攻击面就越大。 3. 版本锁定
许多开发者都遇到过这种情况：
// package.json文件
{
"dependencies": {
"major-framework": "^4.0.0",
"useful-utility": "^2.0.0"
}
}
// 错误：useful-utility@2.0.0 要求 major-framework@^3.0.0
恭喜你，现在你被卡住了，无法升级一个包而不会破坏另一个包。
何时自行编写代码？我的决策框架如下：
- 简单功能
// 不要为此引入库
const chunk = (arr, size) =>
Array.from({ length: Math.ceil(arr.length / size) },
(_, i) => arr.slice(i * size, i * size + size)
);
// 或者这个
const debounce = (fn, ms) => {
let timeoutId;
return (...args) => {
clearTimeout(timeoutId);
timeoutId = setTimeout(() => fn(...args), ms);
};
};
- 核心业务逻辑 你的核心业务逻辑通常应该自定义。这是你产品的差异化所在。
- 性能关键代码 当性能至关重要时，针对特定用例定制的解决方案通常优于通用库。
- 何时使用第三方库 当然，有些情况下使用第三方库是有意义的：
复杂算法
加密2. 数据压缩复杂的数学运算
- - 经过实战检验的解决方案-
身份验证系统4. >数据库ORM >测试框架
- - 标准化解决方案-
UI组件库6. 状态管理工具>HTTP客户端
- - 折中方案：微依赖 有时，你可以找到一个平衡点：
// 不要引入整个lodash库
import get from 'lodash/get' // 只引入需要的部分
// 或者更好的是，尽可能使用原生方法
const get = (obj, path) =>
path.split('.').reduce((acc, part) => acc?.[part], obj);
最佳实践
在添加依赖项之前：
- 审核 检查捆绑包大小的影响、安全漏洞、维护状态。
- 评估 考虑所有成本：学习曲线、集成时间、长期维护、团队熟悉程度。
- 制定删除计划 在你的接口中封装第三方代码，保持实现细节的隔离。
结论
“不要重复造轮子”是一条很好的建议，但并非绝对真理。有时，一个为你的“车”量身定制的轮子比通用的轮子更好。关键在于了解权衡，做出明智的决定。
记住：无论你编写还是引入代码，每一行代码都是你的责任。明智地选择你的责任。
你是否曾经后悔添加依赖项？或者发现自行编写解决方案节省了一天的时间？请在评论中分享你的经验！
