1. 为什么现在可以开始清理 package.json 了如果你维护过超过两年的前端项目打开package.json大概率会看到这样的景象dependencies和devDependencies加起来四五十个包其中有一半你已经想不起来当初为什么装它。更麻烦的是每次npm install都要等半天npm audit报出一堆漏洞升级 Node 版本时总有几个包卡住不动。这个现象背后有一个很直接的原因JavaScript 语言和 Node.js 运行时本身在快速补齐过去需要第三方包才能完成的能力。很多我们习以为常的 npm 包本质上是在语言标准还没跟上时社区给出的临时方案。现在标准跟上了运行时也跟上了这些包就从必需品变成了历史遗留。我最近花了一个周末把一个维护了三年多的中后台项目从 47 个直接依赖精简到 31 个node_modules体积从 380MB 降到 210MB冷启动npm install时间从 90 秒降到 40 秒左右。整个过程没有改一行业务逻辑只是删掉了一些其实早就该删的包。这篇文章就是那次清理的完整复盘。我会挑出 5 个最典型、最值得删的 npm 包讲清楚它们当年为什么存在、现在为什么可以删、删掉之后用什么替代、以及删除过程中容易踩的坑。适合所有还在维护 JavaScript/TypeScript 项目的开发者不管你是刚入行的新手还是写了七八年的老手都能从中找到可以直接抄作业的操作。需要先说明一点可以删不等于必须删。有些包在特定场景下仍然有价值比如你需要兼容非常老的运行环境或者团队有强制的统一规范。我在每一节都会标注清楚适用边界你自己判断。2. 被 TC39 标准吃掉的工具包从 lodash 到原生方法2.1 lodash 的历史地位和现实处境lodash大概是过去十年下载量最高的工具库之一。它诞生于 2012 年那时候 JavaScript 连Array.prototype.includes都没有深拷贝、防抖节流、对象合并这些操作全靠手写或者引入 jQuery 的工具方法。lodash 把几百个常用工具函数打包在一起还做了很好的浏览器兼容一度是每个项目的标配。但现在是 2026 年情况完全变了。我列一下 lodash 里最常用的几个方法以及它们的原生替代lodash 方法原生替代备注_.cloneDeepstructuredClone()Node 17 / 现代浏览器全支持_.debounce/_.throttle手写 20 行或用AbortController配合见下文_.mergeObject.assign 递归或structuredClone后赋值浅合并用Object.assign足够_.uniq/_.uniqBy[...new Set(arr)]/Map去重一行搞定_.get可选链obj?.a?.bES2020 标准_.isEmptyObject.keys(x).length 0一行搞定_.isEqualJSON.stringify对比有局限或手写复杂场景仍需库_.groupByObject.groupBy()ES2024 标准Node 21_.chunk手写 5 行见下文structuredClone是这里最关键的一个。它是 WHATWG 标准的一部分Node 17 开始原生支持Chrome 98、Firefox 94、Safari 15.4 之后全部支持。它能处理循环引用、Date、Map、Set、ArrayBuffer 等类型唯一不能处理的是函数和 DOM 节点。对于 90% 的深拷贝场景它已经完全够用。// 以前 import _ from lodash; const copy _.cloneDeep(original); // 现在 const copy structuredClone(original);Object.groupBy是 ES2024 的新特性Node 21 开始支持Chrome 117 之后也支持了。以前用 lodash 的_.groupBy要引入整个库现在一行原生代码搞定const items [ { type: fruit, name: apple }, { type: veg, name: carrot }, { type: fruit, name: banana }, ]; // 以前 // const grouped _.groupBy(items, type); // 现在 const grouped Object.groupBy(items, (item) item.type); // { fruit: [...], veg: [...] }2.2 防抖节流为什么还是建议手写有人会问防抖节流原生没有替代啊为什么也建议删 lodash答案是这两个函数手写成本极低而且手写版本更容易控制行为。lodash 的debounce功能很全支持leading、trailing、maxWait、cancel、flush但这也意味着它的实现有 200 多行打包进产物里是实打实的体积。而大多数项目实际只用到最基础的延迟执行和取消。function debounce(fn, delay 300) { let timer null; const debounced (...args) { if (timer) clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); timer null; }, delay); }; debounced.cancel () { if (timer) clearTimeout(timer); timer null; }; return debounced; } function throttle(fn, interval 300) { let last 0; return (...args) { const now Date.now(); if (now - last interval) { last now; fn.apply(this, args); } }; }这 20 行代码覆盖了 95% 的使用场景而且没有 tree-shaking 的烦恼。lodash 虽然支持按需引入import debounce from lodash/debounce但很多项目还是习惯import _ from lodash一引入就是 70KB 起步。2.3 删 lodash 的边界条件不是所有项目都能无脑删。以下几种情况建议保留项目需要兼容 IE11 或非常老的移动端浏览器虽然 2026 年这种情况已经很少了大量使用_.isEqual做复杂对象深度比较且对性能敏感团队有强制的代码规范不允许手写工具函数如果只是用了一两个方法最稳妥的做法是先统计实际用到了哪些 lodash 方法逐个替换最后确认没有遗漏再删包。可以用grep -r _\. src/或者 ESLint 的no-restricted-imports规则来辅助排查。3. 运行时已经内置的能力node-fetch、dotenv、rimraf 的退场3.1 node-fetch 为什么不再需要node-fetch是 Node.js 生态里最经典的补丁包之一。Node 18 之前服务端没有原生的fetchAPI想发 HTTP 请求要么用http模块手写要么用axios、request、node-fetch这些库。node-fetch因为 API 和浏览器fetch一致成了很多项目的首选。Node 18 开始fetch成为全局 APINode 21 之后彻底稳定。这意味着// 以前 import fetch from node-fetch; const res await fetch(https://api.example.com/data); const data await res.json(); // 现在 const res await fetch(https://api.example.com/data); const data await res.json();完全一样的代码但不需要任何依赖。而且原生fetch基于 undici 实现性能比node-fetch更好还支持AbortController、ReadableStream等现代特性。需要注意的是原生fetch和node-fetch在少数细节上有差异原生fetch不会自动跟随重定向到不同协议比如 http 到 https需要手动处理原生fetch的Response.body是ReadableStreamnode-fetch是 Node Stream原生fetch对Content-Type的解析更严格如果你的项目重度依赖node-fetch的这些行为迁移前要跑一遍集成测试。但大多数场景下直接替换没有任何问题。3.2 dotenv 被 Node 原生 --env-file 取代dotenv的作用是读取.env文件把变量注入process.env。这个需求在 Node 20.6 之后有了原生方案# 以前 node -r dotenv/config app.js # 现在 node --env-file.env app.jsNode 20.6 引入了--env-file参数Node 21.7 又加了--env-file-if-exists可以在文件不存在时不报错。这意味着dotenv这个包在纯 Node 环境下可以彻底删掉了。// .env DATABASE_URLpostgres://localhost:5432/mydb API_KEYabc123 // app.js console.log(process.env.DATABASE_URL); // 直接可用不过有几个坑要注意--env-file不支持变量插值比如URL${HOST}:${PORT}dotenv支持--env-file不会覆盖已存在的环境变量dotenv默认也不覆盖但可以配置如果你的项目用ts-node或nodemon启动需要在启动命令里加上这个参数如果项目里用了变量插值或者需要在代码里动态加载不同的.env文件dotenv仍然有价值。但如果是简单的启动时读一次配置原生方案完全够用。3.3 rimraf 和跨平台删除目录rimraf的名字来自rm -rf作用是跨平台删除文件和目录。Windows 的rmdir和 Unix 的rm -rf行为不一致rimraf帮你抹平了差异。在构建脚本里经常看到{ scripts: { clean: rimraf dist, build: npm run clean tsc } }Node 14.14 开始fs.rm支持了recursive和force选项Node 16 之后稳定import { rm } from node:fs/promises; await rm(dist, { recursive: true, force: true });如果你只是想在 npm script 里删目录还有一个更简单的办法用node -e直接执行{ scripts: { clean: node -e \require(fs).rmSync(dist, { recursive: true, force: true })\ } }这样连rimraf都不用装。当然如果项目里有大量脚本依赖rimraf的命令行接口迁移成本也不高逐个替换即可。3.4 这三个包的删除顺序建议我建议按这个顺序处理先删node-fetch影响面最大但替换最直接跑一遍接口测试就能验证再删rimraf只影响构建脚本改完跑一次npm run build就知道有没有问题最后删dotenv涉及环境变量要确认 CI/CD 流程里的启动命令同步修改每删一个包都建议单独提交一次 commit方便出问题时快速回滚。4. 构建工具链里的冗余从 babel 插件到 postcss 预设4.1 babel/polyfill 早就该删了babel/polyfill在 Babel 7.4 之后就被标记为废弃了官方明确建议改用core-js和regenerator-runtime按需引入。但我在很多老项目里仍然能看到它的身影。这个包的问题在于它会把整个 core-js 全量引入不管你的目标浏览器需不需要。一个简单的项目引入babel/polyfill产物体积直接增加 80KB 以上。正确的做法是// babel.config.js module.exports { presets: [ [babel/preset-env, { useBuiltIns: usage, corejs: 3, targets: 0.5%, last 2 versions, not dead, }], ], };useBuiltIns: usage会分析代码里实际用到的 API只引入对应的 polyfill。配合browserslist配置产物体积能减少 60% 以上。如果你的项目已经用上了 SWC 或 esbuild 做转译那 Babel 整条链路都可以考虑删掉。SWC 的转译速度是 Babel 的 20 倍左右配置也更简单。4.2 autoprefixer 还需要吗autoprefixer是 PostCSS 生态里最常用的插件作用是自动给 CSS 属性加浏览器前缀。比如你写display: flex它会输出display: -webkit-box; display: -ms-flexbox; display: flex。但 2026 年的浏览器市场已经和五年前完全不同Flexbox 在所有现代浏览器里都是标准属性不需要前缀Grid 布局同样不需要前缀gap属性在 Flexbox 里的支持从 Safari 14.1 开始完善position: sticky从 Safari 13 开始支持也就是说如果你的目标浏览器是现代浏览器autoprefixer能做的事情已经非常有限。我实测过一个项目删掉autoprefixer后CSS 产物只减少了 3KB但构建时间快了 15%。当然如果你的项目需要兼容 Safari 12 以下或者有大量用户还在用老版本 Android WebView那autoprefixer仍然有价值。判断标准很简单打开browserslist配置看看目标浏览器列表里有没有 2020 年之前的版本。4.3 postcss-preset-env 的取舍postcss-preset-env的作用是让你提前使用 CSS 新特性它会根据目标浏览器自动转译。比如你写:is()选择器它会帮你转成兼容写法。但这个包的问题和babel/polyfill类似它引入了一整套 CSS 特性转译规则很多你用不到。而且随着浏览器对 CSS 新特性的支持越来越快这个包的价值在快速下降。我的建议是如果项目里只用了少数几个新特性比如nesting、custom-media直接装对应的单个 PostCSS 插件如果项目重度依赖 CSS 新语法且需要兼容老浏览器保留postcss-preset-env如果目标浏览器都是最近两年的版本直接删掉用原生 CSS4.4 构建工具链清理的实操步骤清理构建工具链比清理运行时依赖风险更高因为一旦配置出错整个构建就挂了。我建议按这个流程走先跑一次完整构建记录产物体积和构建时间作为对比基准逐个删除插件每次只删一个删完跑一次构建对比产物差异用source-map-explorer或webpack-bundle-analyzer分析产物确认没有引入意外的全量包在 CI 里加一条体积检查防止后续又引入大包# 分析产物构成 npx source-map-explorer dist/**/*.js # 或者用 vite 的项目 npx vite-bundle-visualizer这里有个经验删构建插件时优先删那些锦上添花的最后删雪中送炭的。比如autoprefixer属于前者删了最多是样式在老浏览器上有点问题而babel/preset-env属于后者删了代码可能直接跑不起来。5. 那些被误认为必须的包cross-env、concurrently、npm-run-all5.1 cross-env 的原生替代方案cross-env解决的是在 Windows 上设置环境变量语法和 Unix 不一样的问题。以前写 npm script{ scripts: { dev: cross-env NODE_ENVdevelopment node server.js } }Windows 的 cmd 不认NODE_ENVdevelopment这种写法所以需要cross-env来抹平差异。但现在有两个原生方案方案一用 Node 的--env-file{ scripts: { dev: node --env-file.env.development server.js } }方案二用node -e设置后启动{ scripts: { dev: node -e \process.env.NODE_ENVdevelopment; require(./server.js)\ } }方案三直接在代码里判断// server.js const env process.env.NODE_ENV || development;如果你的项目只在少数几个 script 里用了cross-env迁移成本很低。但如果几十个 script 都依赖它可以保留毕竟它只有几 KB。5.2 concurrently 和 npm-run-all 的取舍concurrently和npm-run-all都是用来并行或串行执行多个 npm script 的。比如同时启动前端和后端{ scripts: { dev: concurrently \npm:dev:web\ \npm:dev:server\ } }Node 原生没有直接替代品但可以用child_process手写// scripts/dev.js import { spawn } from node:child_process; const tasks [ spawn(npm, [run, dev:web], { stdio: inherit, shell: true }), spawn(npm, [run, dev:server], { stdio: inherit, shell: true }), ]; process.on(SIGINT, () { tasks.forEach((t) t.kill()); process.exit(); });这 10 行代码替代了concurrently的核心功能。但说实话concurrently提供了彩色输出、前缀标记、失败自动终止等实用功能手写版本要完全对齐需要不少代码。我的建议是如果项目里只有一两个地方用到手写替代如果大量使用保留concurrently。npm-run-all的情况类似它的串行执行功能可以用替代但并行和通配符匹配功能手写成本较高。5.3 判断该不该删的三个标准面对一个不确定要不要删的包我会问自己三个问题第一它解决的问题现在语言或运行时原生支持了吗如果支持了优先用原生方案。原生方案没有版本升级的烦恼也不会因为包作者停止维护而变成安全隐患。第二删掉它需要改多少代码如果只需要改几行那就删如果要改几十个文件那就要权衡收益和成本。第三它带来的体积和构建时间开销有多大用npm ls package看看它的依赖树如果它自己又依赖了十几个包那删掉它的收益就很大。我整理了一个简单的决策表包名原生替代迁移成本建议lodashstructuredClone / Object.groupBy中按需替换后删除node-fetch全局 fetch低直接删除dotenv--env-file低直接删除rimraffs.rm低直接删除babel/polyfillcore-js 按需引入中替换后删除autoprefixer无现代浏览器不需要低视目标浏览器决定cross-env--env-file / node -e低视 script 数量决定concurrentlychild_process中视使用频率决定6. 清理过程中的踩坑记录和验证方法6.1 删包之后构建挂了怎么办我第一次删node-fetch的时候构建直接报错fetch is not defined。排查了半天才发现项目的tsconfig.json里lib配置的是ES2020没有包含DOM所以 TypeScript 不认识全局fetch。解决办法是在tsconfig.json里加上{ compilerOptions: { lib: [ES2022, DOM], types: [node] } }或者装types/node的最新版本它已经包含了fetch的类型定义。这个坑的教训是删包之前先确认 TypeScript 的类型配置能覆盖原生 API。类似的还有structuredClone需要在lib里包含ES2021以上。6.2 如何确认一个包真的没被用到最稳妥的办法是用工具扫描而不是靠肉眼 grep。我常用的是depchecknpx depcheck它会列出所有在package.json里声明但代码里没引用的包以及代码里引用了但没声明的包。输出大概长这样Unused dependencies * lodash * node-fetch * rimraf Unused devDependencies * babel/polyfill * autoprefixer Missing dependencies * types/node但depcheck有个局限它只能检测静态import对于动态require、配置文件里引用的包比如postcss.config.js里的插件可能识别不到。所以扫描结果只能作为参考最终还是要跑一遍完整构建和测试。6.3 删包后的验证清单每次删完包我都会跑一遍这个清单npm install能正常完成没有报错npm run build能正常构建产物体积符合预期npm test全部通过没有因为删包导致的测试失败npm run dev能正常启动页面功能正常npm audit没有新增高危漏洞CI 流水线能跑通包括 lint、type-check、build、test如果项目有 E2E 测试那更好跑一遍 E2E 基本能覆盖大部分回归问题。6.4 一个容易被忽略的坑间接依赖删掉直接依赖后有时候代码还能跑因为间接依赖里还有这个包。比如你删了node-fetch但某个其他包依赖了它node_modules里还有代码里import node-fetch仍然能工作。这种情况最危险因为一旦那个间接依赖升级或删除你的代码就会突然挂掉。验证方法是# 查看某个包是否还在 node_modules 里 npm ls node-fetch # 如果显示为空说明真的删干净了如果npm ls显示还有但不在你的package.json里那就是间接依赖。这时候要么把代码里的引用彻底改掉要么在package.json里显式声明不推荐等于没删。6.5 关于 npm 镜像源和安装速度清理依赖的过程中npm install会跑很多次。如果你觉得慢可以配置国内镜像源npm config set registry https://registry.npmmirror.com或者用pnpm替代npm它的硬链接机制能让安装速度快好几倍而且磁盘占用更小。我那个项目从npm切到pnpm后node_modules体积从 210MB 降到 120MB冷启动安装时间从 40 秒降到 15 秒。不过pnpm对某些老包的兼容性不如npm切换前建议先在测试环境验证一遍。7. 清理之后我的项目变成了什么样那次清理之后我那个中后台项目的package.json从 47 个直接依赖降到 31 个具体变化是这样的指标清理前清理后变化直接依赖数量4731-34%node_modules 体积380MB210MB-45%冷启动 npm install90s40s-56%生产构建时间45s32s-29%产物 JS 体积1.8MB1.4MB-22%npm audit 漏洞数123-75%这些数字不是重点重点是维护成本降低了。以前每次升级 Node 版本都要等 lodash、node-fetch 这些包发布兼容版本现在用的都是原生 APINode 升级基本无感。以前npm audit报一堆漏洞要逐个评估影响现在依赖少了漏洞也少了。当然清理不是一劳永逸的。新项目开始时会很干净但随着业务迭代又会慢慢引入新的包。我的做法是在 CI 里加一条规则每次 PR 如果新增了依赖必须在描述里说明为什么不能用原生方案替代。这条规则执行了半年新引入的依赖数量控制在 5 个以内。最后分享一个我个人的判断习惯每次想装一个新包之前先花 5 分钟搜一下这个功能原生支持了吗。很多时候你会发现标准已经跟上了只是你的知识还停留在几年前。这个习惯帮我省下了至少十几个不必要的依赖。