前阵子接手一个维护了三四年的老项目跑完npm install之后我习惯性地看了眼依赖树发现node_modules里躺着 800 多个包。再顺着package.json数了一遍直接依赖dotenv、moment、lodash、axios、uuid 一个不少——都是前几年大家特别爱装的“必备件”我也不例外我自己发到 npm 上的好几个小工具包里也带过它们。可站在 2026 年回头看这 5 个包至少一半以上的使用场景早已经被 Node 运行时、浏览器平台和 ECMAScript 标准库收编了。删掉它们安装速度、构建体积、供应链攻击面都能实打实地变好而且代码不会少任何一个能力。这篇文章就把每个包为什么能删、用什么替代、边界条件在哪、迁移时容易踩什么坑一次讲清楚。1. 为什么说 2026 年是一个“删包”的好时机1.1 运行时的“内置化”速度比大多数人感知的要快很多团队对 npm 包的依赖习惯其实还停在 2020 年前后的环境认知里。那时候 Node 12 还是主流浏览器要兼容 IE11前端代码动不动要配一大串 polyfill很多工具函数只能靠第三方包兜底。但从 2020 到 2025 这几年运行时和标准库的补位速度非常快。fetch从 Node 18 开始全局可用到 Node 21 以后基本稳定crypto.randomUUID()在 Node 14.17 就有了浏览器端也早已普及Object.hasOwn、Array.prototype.at、String.prototype.replaceAll、structuredClone这些过去要 polyfill 的 API现在都成了语言标准的一部分。更别说 Node 20.6 开始支持--env-file把 dotenv 的核心功能直接做进了运行时。到了 2026 年Node 22 LTS 和 Node 24 LTS 是绝对的主流现代浏览器的基线也早就到了 ES2022 以上。也就是说当年装那些包的理由——兼容性、平台能力缺失——已经不存在了。如果你还在用 IE11 或者 Node 14 以下的版本那确实另当别论但正常维护中的项目早就不该有这种包袱了。1.2 供应链安全让“最小依赖”从洁癖变成刚需这几年 npm 生态里出现过不止一次规模不小的投毒事件攻击者往往不挑那些大而全的框架专门盯着被广泛引用的小包下手——维护者账号被盗、恶意版本悄悄发布、依赖混淆攻击套路已经非常成熟。任何一个包只要还在你的依赖树里它的发布权限、传递依赖、历史版本本质上都是你代码库的一部分信任链。所以很多团队现在做依赖治理考量的已经不是“这个包好不好用”而是“这个包值不值得我承担这份风险”。每多一个直接依赖平均会带来几十个传递依赖任何一个环节出问题整条链都可能受影响。这种事在大厂的安全公告里看多了以后我对“最小依赖原则”的态度就从可维护性偏好变成了实打实的安全诉求。1.3 删掉 5 个包到底能换来什么很多人觉得这几个包体积不大删不删无所谓。但账不是这么算的。第一个收益是依赖树的直接瘦身。lodash 全量打包后 min 大概 70KBgzip 约 24KBmoment 全量 UMD 包 min 约 68KBgzip 约 19KBaxios 打包后 gzip 也有 10KB 上下。这几个包加一起再加上各自的传递依赖、类型声明、版本解析记录会让package-lock.json或pnpm-lock.yaml长出十几甚至几十个间接条目。第二个收益是安装和构建时间。每多一个包npm install就要多做一次版本解析、下载、解压、构建。本地开发机器还好CI 环境和 Docker 构建里这些开销是实打实的分钟级成本。第三个收益是心智负担。新同事接手项目时看到 package.json 里躺着一堆“不知道干嘛用”的依赖要么不敢动要么瞎猜最后往往变成历史包袱。我自己的体验是删完这几个包之后npm install的输出明显变短构建产物体积变小ESLint 和类型检查的报错也少了一类容易混淆的来源。这个账算得过来。2. 配置与 ID 生成dotenv、uuid 这两个包已经没存在的必要2.1 dotenv原生--env-file和loadEnvFile已经成熟dotenv 这个包本身不大核心逻辑就是解析.env文件、把键值对灌进process.env。但它的价值在过去是因为 Node 没有这个能力大家只能用第三方包。Node 20.6 开始官方提供了--env-file参数直接在执行脚本时加载环境变量文件Node 20.12 和 21.7 又补上了process.loadEnvFile()这个运行时方法。最直接的迁移方式就是把启动命令改一下{ scripts: { start: node --env-file.env src/index.js, dev: node --env-file.env --watch src/index.js } }TypeScript 项目也支持只是多一个 loader 参数node --env-file.env --import tsx src/index.tsDocker 镜像里的启动命令同样可以这样写CMD [node, --env-file.env, dist/main.js]如果不想依赖启动参数也可以在入口文件里主动调用if (process.env.NODE_ENV ! production) { process.loadEnvFile(.env); }这里注意一个细节--env-file的行为和 dotenv 的默认行为是一致的——文件里的变量不会覆盖已存在的环境变量。也就是说 CI 平台上通过系统环境变量注入的配置优先级始终高于.env文件这个语义不用改。2.2 uuidcrypto.randomUUID()一行搞定uuid 这个包更没必要留。Node 14.17 以后node:crypto模块自带randomUUID()实现的就是标准 UUID v4随机数来源是加密安全级别的。浏览器端crypto.randomUUID()也早就普及了。替换起来几乎没有成本import { randomUUID } from node:crypto; const id randomUUID(); // 输出形如 6d9b2b1f-8a1a-4d7a-b7e1-3a1c1e2f3a4b浏览器环境直接写const id crypto.randomUUID();很多人担心这个 API 的兼容性其实到 2026 年还在用 Node LTS 版本的项目完全不用担心。真正需要额外考虑的是你生成的是不是必须是 v4 格式。crypto.randomUUID()默认就是 v4这覆盖了绝大多数业务主键、会话 ID、文件名前缀的场景。如果某些老系统对 UUID 格式有历史要求比如必须用 v1 的基于时间戳排序那才需要继续用 uuid 包否则一律用原生的就完事了。2.3 换掉 dotenv 之前先确认这几个边界说归说dotenv 有几种用法是原生能力没有直接覆盖的迁移之前要先想清楚。第一种是依赖dotenv-expand做变量展开的场景。.env文件里写PORT${BASE_PORT} 1或引用其他变量这种复杂的展开逻辑Node 原生的--env-file并不完全等价。新版本 Node 对变量展开的支持一直在完善但不同版本表现有差异。如果你重度依赖展开功能建议先写一个小函数或者在启动脚本里用 shell 做一层拼接别直接硬切。第二种是多个环境文件。dotenv 生态里常见的.env.development、.env.production、.env.local这种按环境加载的写法原生参数没法自动合并多个文件。我的做法是分场景处理环境差异比较大的配置交给 CI 平台注入环境变量本地开发时就用一个.env文件最多在入口处用process.loadEnvFile手动按顺序加载两个文件自己控制优先级。第三种是测试环境。Jest 和 Vitest 里加载.env的逻辑不太一样。Vitest 支持--env-file或环境配置Jest 则要写一个 setup 文件在里面调用process.loadEnvFile(.env)。改动不大但确实需要额外处理不能只改 package.json 里的 scripts 就完事。提示--env-file的具体行为因 Node 版本略有差异动手迁移前先在你的目标运行环境里跑一次node --env-file.env -e console.log(process.env.YOUR_KEY)验证一下比看文档猜行为靠谱得多。3. 工具函数库如何体面地从 lodash 和 moment 迁移出来3.1 lodash 高频方法替换清单一张表说清楚lodash 最尴尬的地方在于它的很多方法当年填补的是 ES5/ES6 时代的空白但 ECMAScript 标准后来把这些能力一个接一个地做了进去。拿业务代码里最常用的几个场景来说原生替代已经完全够用场景lodash 旧写法原生替代注意点安全读取属性_.get(obj, a.b.c)可选链obj?.a?.b?.c动态字符串路径仍需自己解析深拷贝_.cloneDeep(obj)structuredClone(obj)不支持函数、DOM 节点、类实例去重_.uniq(array)[...new Set(array)]uniqBy要用 Map 手动实现拍平数组_.flattenDeep(array)array.flat(Infinity)注意flat()默认只拍一层分组_.groupBy(arr, fn)Object.groupBy(arr, fn)ES2024Node 21 / 现代浏览器取最后一项_.last(arr)arr.at(-1)ES2022 标准防抖/节流_.debounce(fn, 300)手写 15 行或使用框架内置纯函数场景可保留独立小包这里我想特别提醒两个容易踩坑的点。第一个是structuredClone并不能完全替代_.cloneDeep。它支持循环引用、支持Date、Map、Set、ArrayBuffer这些类型但遇到函数、DOM 元素、类实例会直接抛DataCloneError。如果业务代码里有人传了带方法对象进去迁移后会在运行时突然报错。稳妥的做法是先全局搜索cloneDeep的调用点逐个确认参数类型再分批替换为用户自己写的cloneWithFunctions之类的浅层处理函数。第二个是_.get和可选链在动态路径上的差异。_.get(obj, a.b.c)接受一个字符串路径运行时解析可选链obj?.a?.b?.c是静态语法写死了路径。如果项目里有大量从配置或接口返回里动态拼路径的需求手写一个支持a.b.c格式的get函数并不难大约 10 行代码没必要为了这个留着一整个 lodash。3.2 moment 的替代路线Intl 家族 少量手写封装moment 是我见过“早该退役但一直没退役”最典型的包。它的几个核心痛点想必各位都有体感体积大且不可 tree-shaking对象是可变对象m.clone()没调用好会出各种诡异 bugAPI 设计跟现代 JavaScript 风格格格不入。2026 年做日期时间处理的正确姿势是围绕Intl系列 API 写一层薄薄的自己用着顺手的封装。格式化日期用Intl.DateTimeFormatconst formatter new Intl.DateTimeFormat(zh-CN, { year: numeric, month: 2-digit, day: 2-digit, hour: 2-digit, minute: 2-digit, }); formatter.format(new Date()); // 2026/05/18 14:30相对时间显示用Intl.RelativeTimeFormatconst rtf new Intl.RelativeTimeFormat(zh-CN, { numeric: auto }); rtf.format(-3, day); // 3天前时区展示层转换也可以在DateTimeFormat里直接指定timeZonenew Intl.DateTimeFormat(zh-CN, { timeZone: Asia/Shanghai, dateStyle: full, }).format(new Date());我自己的迁移经验是给团队封装一个lib/datetime.ts只暴露业务真正需要的三四个函数——formatDate、formatDateTime、relativeTime、startOfDay。内部全部用原生 API 实现调用方从 moment 直接换成这个模块改动量比想象中小得多。3.3 什么情况下不要硬换先分清“库”和“业务模型”虽然我建议删掉 moment 和 lodash但有一个前提你的用法得是在“函数库”这个层级。如果你的业务模型已经建立在 moment 对象或者 lodash 的深合并语义上那就要谨慎一些。比如_.merge。业务代码里如果依赖深合并而且行为要求跟 lodash 完全一致原生 JavaScript 并没有一个直接等价的方法。structuredClone是替换不是合并Object.assign是浅拷贝不是深合并。如果项目里有大量配置对象合并逻辑建议拆包替换单独引一个lodash.merge或者deepmerge这样的极简包而不是为了一个函数留一整个 lodash。再比如 moment 的时区计算。moment-timezone在“把一个时间戳转换到指定 IANA 时区并继续做计算”这件事上确实做得细致Intl的formatToParts虽然能做展示层转换但要完整替代时区计算逻辑需要维护的代码比你想象的多。如果老项目里到处是moment().tz(Asia/Shanghai).startOf(week)这种链式调用我不会建议一口气全改完更合理的方式是新代码一律走Intl封装老代码按模块渐进重构把 moment 的使用范围逐步压缩到某几个文件里最后再删包。4. HTTP 请求axios 可以退居二线但前提是这些条件4.1 原生 fetch 在 2026 年还缺什么axios 的历史地位不用多说它是 XHR 时代最成功的封装之一。但 2026 年的现实是Node 18 内置 fetch浏览器端 fetch 更是标准能力大部分项目的“发请求”需求其实非常简单——GET、POST、带个 token、处理下错误码、超时就报错。这些用原生 fetch 完全能写而且写出来的代码更直白没有 axios 那层 adapter 魔法。但要说清楚axios 相对原生 fetch 确实还有一些当时卖得很好的能力缺口拦截器axios 的请求/响应拦截器是它最大的心智模型优势。超时控制axios 有timeout配置fetch 需要手动配合AbortController。自动 JSON 序列化axios 会自动JSON.stringify请求体和JSON.parse响应fetch 都要手动处理。上传进度fetch 至今没有原生的上传进度事件只能靠ReadableStream或退回 XHR。前三个能力自己封装并不难真正麻烦的是第四个。如果一个项目对上传进度有硬需求又不想自己造轮子那继续留在 axios 或 XHR 方案里是有合理性的。这一点下面会细说。4.2 自己写一个够用的请求层30 行代码示范如果你只是需要“带超时、带 JSON、能取消”的基础请求能力一个迷你请求层就够了type RequestOptions { baseURL?: string; timeout?: number; headers?: Recordstring, string; signal?: AbortSignal; }; class Http { constructor( private baseURL , private defaultTimeout 10_000, ) {} requestT( method: string, url: string, body?: unknown, options: RequestOptions {}, ): PromiseT { const controller new AbortController(); const timer setTimeout(() controller.abort(), options.timeout ?? this.defaultTimeout); // 合并外部取消信号 if (options.signal) { options.signal.addEventListener(abort, () controller.abort()); } return fetch(this.baseURL url, { method, headers: { Content-Type: application/json, ...this.authHeaders(), ...options.headers, }, body: body undefined ? undefined : JSON.stringify(body), signal: controller.signal, }) .then((res) { if (!res.ok) { throw new Error(HTTP ${res.status}: ${res.statusText}); } return res.status 204 ? (undefined as T) : (res.json() as PromiseT); }) .finally(() clearTimeout(timer)); } private authHeaders(): Recordstring, string { const token localStorage.getItem(token); return token ? { Authorization: Bearer ${token} } : {}; } getT(url: string, options?: RequestOptions) { return this.requestT(GET, url, undefined, options); } postT(url: string, body?: unknown, options?: RequestOptions) { return this.requestT(POST, url, body, options); } } export const http new Http(/api);这段代码覆盖了基础 URL、超时、token 注入、JSON 处理和取消请求。真正的 axios 拦截器机制本质上就是把所有请求和响应处理逻辑放进一个数组里统一遍历你完全可以在request方法里加一个beforeRequest钩子数组实现同样的扩展能力。4.3 把这些项目继续留在 axios别瞎折腾诚实地说有些项目我是建议继续用 axios 的别为了删而删。第一种是已经有大量 axios 封装的存量项目。代码里到处是instance.interceptors.request.use(...)、CancelToken、自定义transformResponse这些东西全量替换成 fetch 其实工作量非常大而且收不到什么明显收益。这种情况下更现实的方案是新代码用原生 fetch 或新封装老代码继续 axios等代码重构到一定程度再整体切换。第二种是强依赖上传进度的项目。fetch 在这个场景下没有现成的upload.onprogress实现成本较高。如果团队没有专门的人愿意趟这个坑保留 axios 是理性的选择。第三种是团队新成员较多、需要统一认知的项目。axios 的文档和社区经验非常丰富新人上手成本低自己封装一套东西反而要写专门的内部文档。这个因素在商业项目里经常被低估。所以我对 axios 的结论不是“今天就必须删”而是“它已经从默认选择变成了可选选择”。如果你只是在fetch外面薄薄包了一层那就果断把整套 axios 拆掉。5. 删包实操从依赖体检到平滑上线的完整步骤5.1 删包前先做一次“依赖体检”不要一上来就改代码。先花半小时把项目的依赖家底摸清楚。第一步看直接依赖列表npm ls --depth0 # 或 pnpm list --depth0这会列出你声明在package.json里的所有直接依赖。先圈定哪些是真正在代码里import过、哪些是只用在 scripts 里、哪些是早就没人用但一直没删的。第二步用工具查未使用依赖。我自己常用的组合是knip加depchecknpx knip npx depcheckknip能查出项目中声明了但没有任何文件引用的依赖还能检测未使用的导出和文件depcheck更适合快速扫描一次直接依赖的使用情况。两者交叉验证一下基本能确定哪些包可以“闭眼删”。第三步查传递依赖。有些包虽然你的代码没直接用但它是另一个包的必要依赖删掉直接依赖会导致间接依赖也被清理从而影响运行。所以删之前用npm why pkg或pnpm why pkg确认一下这个包是被直接引用的还是只是传递依赖链上的一环。5.2 单包替换、分批提交、逐项回归我强烈建议一个包一批提交不要一口气把所有替换写进一个 PR。比如第一周只做uuid - crypto.randomUUID()第二周做dotenv - --env-file第三周再处理 lodash 或 moment。分开走的好处有三个出问题时二分手很快reviewer 能看清楚每处改动回滚也只需要回滚一个小提交。每个包的具体替换流程我的套路是固定的全局搜索该包的所有引用点统计使用范围。逐个文件替换为原生 API 或自己的封装函数。跑 TypeScript 类型检查看有没有漏网之鱼。跑单测、集成测试、关键路径的 E2E。从package.json删除该依赖重新安装并更新 lockfile。构建一次对比产物体积和依赖树是否明显变小。这里要特别提醒一件事删包后 lockfile 的更新。很多人会在代码里删掉 import但忘记更新package-lock.json或pnpm-lock.yaml。结果就是 CI 里依然安装着旧依赖本地构建跟 CI 行为不一致。正确做法是改完package.json之后重新执行一次完整的安装命令确认node_modules里确实没有残留再提交 lockfile 变更。5.3 团队层面如何防止老依赖“复活”代码层面删干净了真正的挑战是防止后续 PR 里又有人把老包引回来。经验丰富的人不会靠自觉来维持依赖纪律而是用工具和文档把规则固化下来。第一个工具是 ESLint。用no-restricted-imports规则直接禁止新代码引入已经被淘汰的包{ rules: { no-restricted-imports: [error, { paths: [lodash, moment, axios] }] } }如果希望 package.json 里也不能再出现这些依赖名配合eslint-plugin-import的import/no-restricted-packages规则更彻底{ rules: { import/no-restricted-packages: [error, [lodash, moment, axios]] } }第二个是项目文档。在 README 或docs/coding-standards.md里明确列出“项目禁用库清单”并写明替代 API 和用法示例。新人入职看一遍文档比 review 时反复提醒效率高得多。第三个是 CI 检查。可以在流水线里加一个简单的脚本扫描package.json里是否出现禁用依赖名一旦发现就 fail。工具不用多高级一段grep加一行判断就能跑起来。6. 还有几个包可以顺手清掉cors、rimraf、mkdirp6.1 cors三行响应头的事不值得多一个依赖很多 Express 项目会装cors中间件来支持跨域。但你要真看它做了什么核心无非是设几个响应头、处理一下 OPTIONS 预检请求。自己写一个中间件非常简单import type { NextFunction, Request, Response } from express; export function corsMiddleware(req: Request, res: Response, next: NextFunction) { res.setHeader(Access-Control-Allow-Origin, req.headers.origin ?? *); res.setHeader(Access-Control-Allow-Methods, GET,POST,PUT,PATCH,DELETE,OPTIONS); res.setHeader(Access-Control-Allow-Headers, req.headers[access-control-request-headers] ?? Content-Type, Authorization); res.setHeader(Access-Control-Max-Age, 600); if (req.method OPTIONS) { res.sendStatus(204); return; } next(); }用 Express 5 或者 Hono 这类新框架的话CORS 支持往往已经内置了更没必要装额外的包。唯一要提醒的是生产环境不要直接把req.headers.origin原样回写应该维护一个允许的域名白名单把 origin 映射到固定的响应值避免被任意站点跨域调用。6.2 rimraf 和 mkdirpNode 原生 fs 早已覆盖rimraf在当年是 Windows 上递归删除目录的救星因为fs.rmdirSync对非空目录会直接报错。但 Node 12.10 之后就有了fs.rm和fs.rmSync支持recursive和force参数。清理构建目录的脚本可以这样写{ scripts: { clean: node -e \require(node:fs).rmSync(dist,{recursive:true,force:true})\ } }mkdirp同理fs.mkdirSync的{ recursive: true }参数从 Node 10.12 就有了连续创建多层目录再也不用第三方包。这两个包删掉之后依赖树能少好几个 Windows 兼容相关的传递依赖。6.3 给自己的 package.json 立几条规矩经过这几轮删包之后我慢慢养成了一套依赖管理习惯分享出来给各位参考。新项目起步时我默认从零依赖开始需要什么功能先问一句原生 API 能不能做做不到再找最小型的第三方包。每加一个依赖都得能回答“它解决了什么问题为什么原生做不到”。老项目维护时我一季度做一次依赖体检重点关注那些“没人维护但没被删”的包能删就删。我也很推荐给团队建立一个“依赖门槛”清单比如体积超过某个阈值必须有 tree-shaking 证明新引入的包必须有人回答维护状态和替代方案超过一年没更新的包要打上“高危观察”标签。这些规矩不一定需要工具强制执行但写下来之后至少能在 review 时给“为什么要加这个包”留一个讨论空间。最后分享一点个人经验删包这件事难的不是代码替换而是心态。很多开发者觉得“多加一个包又不会怎么样”但维护久了你会发现依赖树是一点一点失控的今天加一个工具函数明天加一个语法糖包半年后npm audit报告里全是红字谁都不敢动了。我自己的底线是新代码尽量不引入新依赖旧代码按批次清理宁可自己多写 10 行原生代码也不为了省 10 分钟接入一个没人维护的“小工具”。2026 年的 JavaScript 生态原生能力已经足够你写出干净、稳健、不心虚的代码了。
前阵子接手一个维护了三四年的老项目跑完npm install之后我习惯性地看了眼依赖树发现node_modules里躺着 800 多个包。再顺着package.json数了一遍直接依赖dotenv、moment、lodash、axios、uuid 一个不少——都是前几年大家特别爱装的“必备件”我也不例外我自己发到 npm 上的好几个小工具包里也带过它们。可站在 2026 年回头看这 5 个包至少一半以上的使用场景早已经被 Node 运行时、浏览器平台和 ECMAScript 标准库收编了。删掉它们安装速度、构建体积、供应链攻击面都能实打实地变好而且代码不会少任何一个能力。这篇文章就把每个包为什么能删、用什么替代、边界条件在哪、迁移时容易踩什么坑一次讲清楚。1. 为什么说 2026 年是一个“删包”的好时机1.1 运行时的“内置化”速度比大多数人感知的要快很多团队对 npm 包的依赖习惯其实还停在 2020 年前后的环境认知里。那时候 Node 12 还是主流浏览器要兼容 IE11前端代码动不动要配一大串 polyfill很多工具函数只能靠第三方包兜底。但从 2020 到 2025 这几年运行时和标准库的补位速度非常快。fetch从 Node 18 开始全局可用到 Node 21 以后基本稳定crypto.randomUUID()在 Node 14.17 就有了浏览器端也早已普及Object.hasOwn、Array.prototype.at、String.prototype.replaceAll、structuredClone这些过去要 polyfill 的 API现在都成了语言标准的一部分。更别说 Node 20.6 开始支持--env-file把 dotenv 的核心功能直接做进了运行时。到了 2026 年Node 22 LTS 和 Node 24 LTS 是绝对的主流现代浏览器的基线也早就到了 ES2022 以上。也就是说当年装那些包的理由——兼容性、平台能力缺失——已经不存在了。如果你还在用 IE11 或者 Node 14 以下的版本那确实另当别论但正常维护中的项目早就不该有这种包袱了。1.2 供应链安全让“最小依赖”从洁癖变成刚需这几年 npm 生态里出现过不止一次规模不小的投毒事件攻击者往往不挑那些大而全的框架专门盯着被广泛引用的小包下手——维护者账号被盗、恶意版本悄悄发布、依赖混淆攻击套路已经非常成熟。任何一个包只要还在你的依赖树里它的发布权限、传递依赖、历史版本本质上都是你代码库的一部分信任链。所以很多团队现在做依赖治理考量的已经不是“这个包好不好用”而是“这个包值不值得我承担这份风险”。每多一个直接依赖平均会带来几十个传递依赖任何一个环节出问题整条链都可能受影响。这种事在大厂的安全公告里看多了以后我对“最小依赖原则”的态度就从可维护性偏好变成了实打实的安全诉求。1.3 删掉 5 个包到底能换来什么很多人觉得这几个包体积不大删不删无所谓。但账不是这么算的。第一个收益是依赖树的直接瘦身。lodash 全量打包后 min 大概 70KBgzip 约 24KBmoment 全量 UMD 包 min 约 68KBgzip 约 19KBaxios 打包后 gzip 也有 10KB 上下。这几个包加一起再加上各自的传递依赖、类型声明、版本解析记录会让package-lock.json或pnpm-lock.yaml长出十几甚至几十个间接条目。第二个收益是安装和构建时间。每多一个包npm install就要多做一次版本解析、下载、解压、构建。本地开发机器还好CI 环境和 Docker 构建里这些开销是实打实的分钟级成本。第三个收益是心智负担。新同事接手项目时看到 package.json 里躺着一堆“不知道干嘛用”的依赖要么不敢动要么瞎猜最后往往变成历史包袱。我自己的体验是删完这几个包之后npm install的输出明显变短构建产物体积变小ESLint 和类型检查的报错也少了一类容易混淆的来源。这个账算得过来。2. 配置与 ID 生成dotenv、uuid 这两个包已经没存在的必要2.1 dotenv原生--env-file和loadEnvFile已经成熟dotenv 这个包本身不大核心逻辑就是解析.env文件、把键值对灌进process.env。但它的价值在过去是因为 Node 没有这个能力大家只能用第三方包。Node 20.6 开始官方提供了--env-file参数直接在执行脚本时加载环境变量文件Node 20.12 和 21.7 又补上了process.loadEnvFile()这个运行时方法。最直接的迁移方式就是把启动命令改一下{ scripts: { start: node --env-file.env src/index.js, dev: node --env-file.env --watch src/index.js } }TypeScript 项目也支持只是多一个 loader 参数node --env-file.env --import tsx src/index.tsDocker 镜像里的启动命令同样可以这样写CMD [node, --env-file.env, dist/main.js]如果不想依赖启动参数也可以在入口文件里主动调用if (process.env.NODE_ENV ! production) { process.loadEnvFile(.env); }这里注意一个细节--env-file的行为和 dotenv 的默认行为是一致的——文件里的变量不会覆盖已存在的环境变量。也就是说 CI 平台上通过系统环境变量注入的配置优先级始终高于.env文件这个语义不用改。2.2 uuidcrypto.randomUUID()一行搞定uuid 这个包更没必要留。Node 14.17 以后node:crypto模块自带randomUUID()实现的就是标准 UUID v4随机数来源是加密安全级别的。浏览器端crypto.randomUUID()也早就普及了。替换起来几乎没有成本import { randomUUID } from node:crypto; const id randomUUID(); // 输出形如 6d9b2b1f-8a1a-4d7a-b7e1-3a1c1e2f3a4b浏览器环境直接写const id crypto.randomUUID();很多人担心这个 API 的兼容性其实到 2026 年还在用 Node LTS 版本的项目完全不用担心。真正需要额外考虑的是你生成的是不是必须是 v4 格式。crypto.randomUUID()默认就是 v4这覆盖了绝大多数业务主键、会话 ID、文件名前缀的场景。如果某些老系统对 UUID 格式有历史要求比如必须用 v1 的基于时间戳排序那才需要继续用 uuid 包否则一律用原生的就完事了。2.3 换掉 dotenv 之前先确认这几个边界说归说dotenv 有几种用法是原生能力没有直接覆盖的迁移之前要先想清楚。第一种是依赖dotenv-expand做变量展开的场景。.env文件里写PORT${BASE_PORT} 1或引用其他变量这种复杂的展开逻辑Node 原生的--env-file并不完全等价。新版本 Node 对变量展开的支持一直在完善但不同版本表现有差异。如果你重度依赖展开功能建议先写一个小函数或者在启动脚本里用 shell 做一层拼接别直接硬切。第二种是多个环境文件。dotenv 生态里常见的.env.development、.env.production、.env.local这种按环境加载的写法原生参数没法自动合并多个文件。我的做法是分场景处理环境差异比较大的配置交给 CI 平台注入环境变量本地开发时就用一个.env文件最多在入口处用process.loadEnvFile手动按顺序加载两个文件自己控制优先级。第三种是测试环境。Jest 和 Vitest 里加载.env的逻辑不太一样。Vitest 支持--env-file或环境配置Jest 则要写一个 setup 文件在里面调用process.loadEnvFile(.env)。改动不大但确实需要额外处理不能只改 package.json 里的 scripts 就完事。提示--env-file的具体行为因 Node 版本略有差异动手迁移前先在你的目标运行环境里跑一次node --env-file.env -e console.log(process.env.YOUR_KEY)验证一下比看文档猜行为靠谱得多。3. 工具函数库如何体面地从 lodash 和 moment 迁移出来3.1 lodash 高频方法替换清单一张表说清楚lodash 最尴尬的地方在于它的很多方法当年填补的是 ES5/ES6 时代的空白但 ECMAScript 标准后来把这些能力一个接一个地做了进去。拿业务代码里最常用的几个场景来说原生替代已经完全够用场景lodash 旧写法原生替代注意点安全读取属性_.get(obj, a.b.c)可选链obj?.a?.b?.c动态字符串路径仍需自己解析深拷贝_.cloneDeep(obj)structuredClone(obj)不支持函数、DOM 节点、类实例去重_.uniq(array)[...new Set(array)]uniqBy要用 Map 手动实现拍平数组_.flattenDeep(array)array.flat(Infinity)注意flat()默认只拍一层分组_.groupBy(arr, fn)Object.groupBy(arr, fn)ES2024Node 21 / 现代浏览器取最后一项_.last(arr)arr.at(-1)ES2022 标准防抖/节流_.debounce(fn, 300)手写 15 行或使用框架内置纯函数场景可保留独立小包这里我想特别提醒两个容易踩坑的点。第一个是structuredClone并不能完全替代_.cloneDeep。它支持循环引用、支持Date、Map、Set、ArrayBuffer这些类型但遇到函数、DOM 元素、类实例会直接抛DataCloneError。如果业务代码里有人传了带方法对象进去迁移后会在运行时突然报错。稳妥的做法是先全局搜索cloneDeep的调用点逐个确认参数类型再分批替换为用户自己写的cloneWithFunctions之类的浅层处理函数。第二个是_.get和可选链在动态路径上的差异。_.get(obj, a.b.c)接受一个字符串路径运行时解析可选链obj?.a?.b?.c是静态语法写死了路径。如果项目里有大量从配置或接口返回里动态拼路径的需求手写一个支持a.b.c格式的get函数并不难大约 10 行代码没必要为了这个留着一整个 lodash。3.2 moment 的替代路线Intl 家族 少量手写封装moment 是我见过“早该退役但一直没退役”最典型的包。它的几个核心痛点想必各位都有体感体积大且不可 tree-shaking对象是可变对象m.clone()没调用好会出各种诡异 bugAPI 设计跟现代 JavaScript 风格格格不入。2026 年做日期时间处理的正确姿势是围绕Intl系列 API 写一层薄薄的自己用着顺手的封装。格式化日期用Intl.DateTimeFormatconst formatter new Intl.DateTimeFormat(zh-CN, { year: numeric, month: 2-digit, day: 2-digit, hour: 2-digit, minute: 2-digit, }); formatter.format(new Date()); // 2026/05/18 14:30相对时间显示用Intl.RelativeTimeFormatconst rtf new Intl.RelativeTimeFormat(zh-CN, { numeric: auto }); rtf.format(-3, day); // 3天前时区展示层转换也可以在DateTimeFormat里直接指定timeZonenew Intl.DateTimeFormat(zh-CN, { timeZone: Asia/Shanghai, dateStyle: full, }).format(new Date());我自己的迁移经验是给团队封装一个lib/datetime.ts只暴露业务真正需要的三四个函数——formatDate、formatDateTime、relativeTime、startOfDay。内部全部用原生 API 实现调用方从 moment 直接换成这个模块改动量比想象中小得多。3.3 什么情况下不要硬换先分清“库”和“业务模型”虽然我建议删掉 moment 和 lodash但有一个前提你的用法得是在“函数库”这个层级。如果你的业务模型已经建立在 moment 对象或者 lodash 的深合并语义上那就要谨慎一些。比如_.merge。业务代码里如果依赖深合并而且行为要求跟 lodash 完全一致原生 JavaScript 并没有一个直接等价的方法。structuredClone是替换不是合并Object.assign是浅拷贝不是深合并。如果项目里有大量配置对象合并逻辑建议拆包替换单独引一个lodash.merge或者deepmerge这样的极简包而不是为了一个函数留一整个 lodash。再比如 moment 的时区计算。moment-timezone在“把一个时间戳转换到指定 IANA 时区并继续做计算”这件事上确实做得细致Intl的formatToParts虽然能做展示层转换但要完整替代时区计算逻辑需要维护的代码比你想象的多。如果老项目里到处是moment().tz(Asia/Shanghai).startOf(week)这种链式调用我不会建议一口气全改完更合理的方式是新代码一律走Intl封装老代码按模块渐进重构把 moment 的使用范围逐步压缩到某几个文件里最后再删包。4. HTTP 请求axios 可以退居二线但前提是这些条件4.1 原生 fetch 在 2026 年还缺什么axios 的历史地位不用多说它是 XHR 时代最成功的封装之一。但 2026 年的现实是Node 18 内置 fetch浏览器端 fetch 更是标准能力大部分项目的“发请求”需求其实非常简单——GET、POST、带个 token、处理下错误码、超时就报错。这些用原生 fetch 完全能写而且写出来的代码更直白没有 axios 那层 adapter 魔法。但要说清楚axios 相对原生 fetch 确实还有一些当时卖得很好的能力缺口拦截器axios 的请求/响应拦截器是它最大的心智模型优势。超时控制axios 有timeout配置fetch 需要手动配合AbortController。自动 JSON 序列化axios 会自动JSON.stringify请求体和JSON.parse响应fetch 都要手动处理。上传进度fetch 至今没有原生的上传进度事件只能靠ReadableStream或退回 XHR。前三个能力自己封装并不难真正麻烦的是第四个。如果一个项目对上传进度有硬需求又不想自己造轮子那继续留在 axios 或 XHR 方案里是有合理性的。这一点下面会细说。4.2 自己写一个够用的请求层30 行代码示范如果你只是需要“带超时、带 JSON、能取消”的基础请求能力一个迷你请求层就够了type RequestOptions { baseURL?: string; timeout?: number; headers?: Recordstring, string; signal?: AbortSignal; }; class Http { constructor( private baseURL , private defaultTimeout 10_000, ) {} requestT( method: string, url: string, body?: unknown, options: RequestOptions {}, ): PromiseT { const controller new AbortController(); const timer setTimeout(() controller.abort(), options.timeout ?? this.defaultTimeout); // 合并外部取消信号 if (options.signal) { options.signal.addEventListener(abort, () controller.abort()); } return fetch(this.baseURL url, { method, headers: { Content-Type: application/json, ...this.authHeaders(), ...options.headers, }, body: body undefined ? undefined : JSON.stringify(body), signal: controller.signal, }) .then((res) { if (!res.ok) { throw new Error(HTTP ${res.status}: ${res.statusText}); } return res.status 204 ? (undefined as T) : (res.json() as PromiseT); }) .finally(() clearTimeout(timer)); } private authHeaders(): Recordstring, string { const token localStorage.getItem(token); return token ? { Authorization: Bearer ${token} } : {}; } getT(url: string, options?: RequestOptions) { return this.requestT(GET, url, undefined, options); } postT(url: string, body?: unknown, options?: RequestOptions) { return this.requestT(POST, url, body, options); } } export const http new Http(/api);这段代码覆盖了基础 URL、超时、token 注入、JSON 处理和取消请求。真正的 axios 拦截器机制本质上就是把所有请求和响应处理逻辑放进一个数组里统一遍历你完全可以在request方法里加一个beforeRequest钩子数组实现同样的扩展能力。4.3 把这些项目继续留在 axios别瞎折腾诚实地说有些项目我是建议继续用 axios 的别为了删而删。第一种是已经有大量 axios 封装的存量项目。代码里到处是instance.interceptors.request.use(...)、CancelToken、自定义transformResponse这些东西全量替换成 fetch 其实工作量非常大而且收不到什么明显收益。这种情况下更现实的方案是新代码用原生 fetch 或新封装老代码继续 axios等代码重构到一定程度再整体切换。第二种是强依赖上传进度的项目。fetch 在这个场景下没有现成的upload.onprogress实现成本较高。如果团队没有专门的人愿意趟这个坑保留 axios 是理性的选择。第三种是团队新成员较多、需要统一认知的项目。axios 的文档和社区经验非常丰富新人上手成本低自己封装一套东西反而要写专门的内部文档。这个因素在商业项目里经常被低估。所以我对 axios 的结论不是“今天就必须删”而是“它已经从默认选择变成了可选选择”。如果你只是在fetch外面薄薄包了一层那就果断把整套 axios 拆掉。5. 删包实操从依赖体检到平滑上线的完整步骤5.1 删包前先做一次“依赖体检”不要一上来就改代码。先花半小时把项目的依赖家底摸清楚。第一步看直接依赖列表npm ls --depth0 # 或 pnpm list --depth0这会列出你声明在package.json里的所有直接依赖。先圈定哪些是真正在代码里import过、哪些是只用在 scripts 里、哪些是早就没人用但一直没删的。第二步用工具查未使用依赖。我自己常用的组合是knip加depchecknpx knip npx depcheckknip能查出项目中声明了但没有任何文件引用的依赖还能检测未使用的导出和文件depcheck更适合快速扫描一次直接依赖的使用情况。两者交叉验证一下基本能确定哪些包可以“闭眼删”。第三步查传递依赖。有些包虽然你的代码没直接用但它是另一个包的必要依赖删掉直接依赖会导致间接依赖也被清理从而影响运行。所以删之前用npm why pkg或pnpm why pkg确认一下这个包是被直接引用的还是只是传递依赖链上的一环。5.2 单包替换、分批提交、逐项回归我强烈建议一个包一批提交不要一口气把所有替换写进一个 PR。比如第一周只做uuid - crypto.randomUUID()第二周做dotenv - --env-file第三周再处理 lodash 或 moment。分开走的好处有三个出问题时二分手很快reviewer 能看清楚每处改动回滚也只需要回滚一个小提交。每个包的具体替换流程我的套路是固定的全局搜索该包的所有引用点统计使用范围。逐个文件替换为原生 API 或自己的封装函数。跑 TypeScript 类型检查看有没有漏网之鱼。跑单测、集成测试、关键路径的 E2E。从package.json删除该依赖重新安装并更新 lockfile。构建一次对比产物体积和依赖树是否明显变小。这里要特别提醒一件事删包后 lockfile 的更新。很多人会在代码里删掉 import但忘记更新package-lock.json或pnpm-lock.yaml。结果就是 CI 里依然安装着旧依赖本地构建跟 CI 行为不一致。正确做法是改完package.json之后重新执行一次完整的安装命令确认node_modules里确实没有残留再提交 lockfile 变更。5.3 团队层面如何防止老依赖“复活”代码层面删干净了真正的挑战是防止后续 PR 里又有人把老包引回来。经验丰富的人不会靠自觉来维持依赖纪律而是用工具和文档把规则固化下来。第一个工具是 ESLint。用no-restricted-imports规则直接禁止新代码引入已经被淘汰的包{ rules: { no-restricted-imports: [error, { paths: [lodash, moment, axios] }] } }如果希望 package.json 里也不能再出现这些依赖名配合eslint-plugin-import的import/no-restricted-packages规则更彻底{ rules: { import/no-restricted-packages: [error, [lodash, moment, axios]] } }第二个是项目文档。在 README 或docs/coding-standards.md里明确列出“项目禁用库清单”并写明替代 API 和用法示例。新人入职看一遍文档比 review 时反复提醒效率高得多。第三个是 CI 检查。可以在流水线里加一个简单的脚本扫描package.json里是否出现禁用依赖名一旦发现就 fail。工具不用多高级一段grep加一行判断就能跑起来。6. 还有几个包可以顺手清掉cors、rimraf、mkdirp6.1 cors三行响应头的事不值得多一个依赖很多 Express 项目会装cors中间件来支持跨域。但你要真看它做了什么核心无非是设几个响应头、处理一下 OPTIONS 预检请求。自己写一个中间件非常简单import type { NextFunction, Request, Response } from express; export function corsMiddleware(req: Request, res: Response, next: NextFunction) { res.setHeader(Access-Control-Allow-Origin, req.headers.origin ?? *); res.setHeader(Access-Control-Allow-Methods, GET,POST,PUT,PATCH,DELETE,OPTIONS); res.setHeader(Access-Control-Allow-Headers, req.headers[access-control-request-headers] ?? Content-Type, Authorization); res.setHeader(Access-Control-Max-Age, 600); if (req.method OPTIONS) { res.sendStatus(204); return; } next(); }用 Express 5 或者 Hono 这类新框架的话CORS 支持往往已经内置了更没必要装额外的包。唯一要提醒的是生产环境不要直接把req.headers.origin原样回写应该维护一个允许的域名白名单把 origin 映射到固定的响应值避免被任意站点跨域调用。6.2 rimraf 和 mkdirpNode 原生 fs 早已覆盖rimraf在当年是 Windows 上递归删除目录的救星因为fs.rmdirSync对非空目录会直接报错。但 Node 12.10 之后就有了fs.rm和fs.rmSync支持recursive和force参数。清理构建目录的脚本可以这样写{ scripts: { clean: node -e \require(node:fs).rmSync(dist,{recursive:true,force:true})\ } }mkdirp同理fs.mkdirSync的{ recursive: true }参数从 Node 10.12 就有了连续创建多层目录再也不用第三方包。这两个包删掉之后依赖树能少好几个 Windows 兼容相关的传递依赖。6.3 给自己的 package.json 立几条规矩经过这几轮删包之后我慢慢养成了一套依赖管理习惯分享出来给各位参考。新项目起步时我默认从零依赖开始需要什么功能先问一句原生 API 能不能做做不到再找最小型的第三方包。每加一个依赖都得能回答“它解决了什么问题为什么原生做不到”。老项目维护时我一季度做一次依赖体检重点关注那些“没人维护但没被删”的包能删就删。我也很推荐给团队建立一个“依赖门槛”清单比如体积超过某个阈值必须有 tree-shaking 证明新引入的包必须有人回答维护状态和替代方案超过一年没更新的包要打上“高危观察”标签。这些规矩不一定需要工具强制执行但写下来之后至少能在 review 时给“为什么要加这个包”留一个讨论空间。最后分享一点个人经验删包这件事难的不是代码替换而是心态。很多开发者觉得“多加一个包又不会怎么样”但维护久了你会发现依赖树是一点一点失控的今天加一个工具函数明天加一个语法糖包半年后npm audit报告里全是红字谁都不敢动了。我自己的底线是新代码尽量不引入新依赖旧代码按批次清理宁可自己多写 10 行原生代码也不为了省 10 分钟接入一个没人维护的“小工具”。2026 年的 JavaScript 生态原生能力已经足够你写出干净、稳健、不心虚的代码了。
