企业官网建设流程全解析

记得我刚写 Node 项目的时候，新项目第一件事就是npm i axios dotenv rimraf uuid chalk。这几个包几乎成了标配：HTTP 请求、环境变量、删目录、生成 ID、终端配色，每一项都像“必须自己装”才能干活。但到了 2026 年再回头看你项目里的package.json，你会发现这套“经典组合”已经变得很冗余——不是这些包不好，而是 Node 和浏览器把该干的事都干完了，而且干得足够好。

这篇文章我想聊 5 个现在完全可以移除的 npm 包，以及它们背后的官方替代方案。适合正在维护 Node/前端项目、想给项目瘦身、或者新开始一个项目不想再把node_modules堆成山的开发者。我会尽量把原理、代码、踩坑点都说清楚，让你看完可以直接照着改。

1. 为什么要清理依赖：2026 年的原生能力地图

1.1 原生运行时已经替你“安装”了什么

先抛开具体包名，看一个更本质的问题：为什么以前我们离不开这些 npm 包？

因为很长一段时间里，Node 和浏览器的标准库确实“缺货”。没有fetch的时候，要发 HTTP 请求只能拼http模块或者上axios；没有递归删除目录能力的时候，只能靠rimraf；没有生成 UUID 的标准 API 时，只能用第三方包；终端 ANSI 颜色更是没有官方 API，只能手写转义字符。

但这几年原生 API 补得非常快。到 2026 年，主流 JavaScript 运行时的能力已经足够覆盖很多日常场景：

• Node 18 开始，fetch成为内置全局函数，不用再引入node-fetch，更不用为了舒服一点引入axios。
• Node 20.6 开始，.env文件可以靠node --env-file直接加载。
• Node 14.14 开始，fs.rm和fs.rmSync就支持递归删除目录了。
• Node 14.17 开始，crypto.randomUUID()就能直接生成标准 UUID v4。
• Node 20.12 开始，util.styleText()给终端彩色输出提供了官方入口。

这不是什么“未来趋势”，而是今天都可以直接用的能力。2026 年的项目如果再为一两个 API 去引入一个全新的依赖树，性价比真的很低。

1.2 删依赖不是炫技，是维护成本的现实问题

很多人觉得“多一个包有什么大不了”，但npm install拉回来的不是一个文件，而是一个依赖树。举个真实例子，axios本身看起来不重，但如果你项目里还混着老版本follow-redirects、form-data、proxy-from-env这些传递依赖，npm audit报出来的一堆漏洞其实就是这些边角料。你未必真的用了它们，但因为装了整个包，就必须一起承担升级压力。

依赖越多，等于把一部分代码正确性外包给了别人。你需要持续关注上游版本的 breaking change，需要忍受npm audit里真假难辨的告警，需要在每次npm ci时多花时间解析依赖。而当你需要的功能只是“发个 GET 请求”“读一下.env”“删掉 dist 目录”的时候，这些代价就显得尤其不划算。

我并不是说所有第三方库都该删。像 React、Vue、Express 这类框架级依赖，删掉它们意味着重写整个项目，不现实。我们要清理的是那些“标准库已经覆盖”的工具型依赖，删完之后不影响功能，代码反而更好掌控。

2. 5 个可以删掉的 npm 包与官方替代方案

2.1 axios：用原生 fetch 加一个小封装

axios是这个列表里最值得聊的。它曾经是前端发请求的事实标准，也确实是好工具：自动 JSON 转换、请求/响应拦截器、取消请求、超时处理……但问题在于，浏览器和 Node 现在都有原生fetch，而这些高级能力中最常用的部分，自己写一个很薄的小封装就能覆盖。

原生fetch和 axios 最大的体验差异有四个：

1. fetch不会自动把响应转成 JSON，需要手动res.json()。
2. fetch默认没有超时，需要结合AbortController。
3. fetch对非 2xx 状态码不会抛异常，需要手动判断res.ok。
4. fetch没有response.data，拿到的是一整个Response对象。

这些差异很好解决。我在项目里一般抽一个request.js：

async function request(url, { method = 'GET', body, headers = {}, timeout = 5000 } = {}) { const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), timeout); try { const response = await fetch(url, { method, headers: { 'Content-Type': 'application/json', ...headers, }, body: body ? JSON.stringify(body) : undefined, signal: controller.signal, }); if (!response.ok) { const error = new Error(`HTTP ${response.status}: ${response.statusText}`); error.status = response.status; error.response = response; throw error; } const text = await response.text(); return text ? JSON.parse(text) : null; } catch (error) { if (error.name === 'AbortError') { throw new Error(`Request timeout after ${timeout}ms: ${url}`); } throw error; } finally { clearTimeout(timer); } } export { request };

这个封装做下来不到 30 行，日常 CRUD 完全够用。如果团队需要拦截器，可以用函数组合的方式统一处理 token、日志、错误上报，不必依赖 axios 的拦截器机制。

什么情况下可以保留 axios？如果你的项目里有大量历史代码依赖它，或者你需要非常复杂的取消机制、上传下载进度、自定义适配器，迁移成本大于收益。但从 2026 年新项目来看，直接删掉axios，用原生fetch起步，是一个很舒服的起点。

2.2 dotenv：用node --env-file直接加载环境变量

dotenv是我以前每个 Node 项目的必装包，因为.env文件解析确实方便。但现在 Node 已经内置了这个能力，不需要再为它加依赖。

最推荐的方式是在启动命令里声明：

node --env-file=.env src/index.js

这样启动应用时，Node 会把.env文件里的KEY=VALUE加载到process.env。和dotenv的默认行为一致：如果系统环境变量里已经存在同名变量，以系统环境变量为准，文件里的值不会覆盖它。

如果你需要在代码内部显式加载，也可以用process.loadEnvFile：

import { loadEnvFile } from 'node:process'; loadEnvFile('.env'); console.log(process.env.DATABASE_URL);

loadEnvFile从 Node 20.12 开始提供，在 2026 年的主流 LTS 版本上运行毫无压力。

迁移的时候要注意：以前dotenv可以让你在任何位置调用require('dotenv').config()，而原生方案更倾向于在进程启动阶段加载。如果你有特殊逻辑，比如根据环境变量动态选择加载不同的.env文件，可以在入口文件顶部调用loadEnvFile。

还有一个常见坑：如果你只是在 npm script 里写了"dev": "node src/index.js"，改成"dev": "node --env-file=.env src/index.js"时，要确保 CI 或生产环境也有对应的.env文件。如果某些环境没有.env文件，会启动报错。Node 22 提供了一个--env-file-if-exists参数，允许“有就加载，没有就跳过”，适合灵活的部署场景。

2.3 rimraf：用fs.rm做跨平台递归删除

rimraf的流行原因很单纯：早期 Node 没有原生递归删除 API，fs.rmdir对非空目录会报错。但现在完全没必要再用它了，因为fs.rm和fs.rmSync已经解决了这件事。

如果你想在代码里删除dist目录：

import { rm } from 'node:fs/promises'; await rm('dist', { recursive: true, force: true });

同步版本：

import { rmSync } from 'node:fs'; rmSync('dist', { recursive: true, force: true });

很多项目并不是在代码里调用 rimraf，而是在package.json的 scripts 里写：

"scripts": { "clean": "rimraf dist" }

这个也可以直接改成：

"scripts": { "clean": "node -e \"require('node:fs').rmSync('dist', { recursive: true, force: true })\"" }

这样在 Windows、macOS、Linux 上都能正常工作，完全跨平台。

recursive: true表示递归删除目录里的内容，force: true表示目标不存在时不报错。这两个参数加起来，基本就是rimraf最常见的使用方式。

需要特别提醒的是：删除目录是危险操作，不要在脚本里写rmSync('/', ...)，也不要把路径变量拼错。建议在删除前先打印一下要删的路径，或者至少用path.resolve把路径限制在项目根目录下。

2.4 uuid：用crypto.randomUUID()生成标准 UUID v4

以前做数据库主键、会话 ID、临时文件名，第一个念头可能都是npm i uuid。现在的原生 API 已经覆盖了最常用的 v4 场景。

Node 端：

import { randomUUID } from 'node:crypto'; const id = randomUUID(); // 例：6b8e3e8e-1a9f-4e2e-9e62-3d8e9128f4a6

浏览器端：

const id = crypto.randomUUID(); // 要求 HTTPS 或 localhost 环境

注意crypto.randomUUID()不是Math.random()的替代，它使用系统提供的 CSPRNG（加密安全伪随机数生成器）。对于 Token、密钥这类需要不可预测性的场景，用Math.random()是错误选择，但用crypto.randomUUID()是正确的。

迁移成本非常低：uuid包 v4 输出也是标准 UUID 格式，和原生randomUUID()完全一致。如果你之前保存过 UUID 到数据库，不需要做任何格式转换，直接替换生成逻辑即可。

唯一要注意的兼容性问题是：浏览器crypto.randomUUID()要求安全上下文，如果你的站点部署在普通 HTTP 上，可能拿不到这个 API。但 2026 年的现代项目基本全站 HTTPS，这个问题影响很小。万一真的需要在非 HTTPS 环境生成 UUID，还是可以用uuid包作为 fallback。

2.5 chalk：用util.styleText做终端彩色输出

终端彩色输出，以前绕不开chalk。它提供了很优雅的链式写法：

import chalk from 'chalk'; console.log(chalk.red('error')); console.log(chalk.bgGreen.black('success'));

但是 Node 从版本 20.12 / 21.7 开始提供了util.styleText()，基本覆盖了最简单、最常用的终端样式需求。

import { styleText } from 'node:util'; console.log(styleText('red', 'error')); console.log(styleText('green', 'success'));

如果需要组合样式，可以传数组：

console.log(styleText(['bold', 'red'], 'Fatal error'));

这跟chalk.red.bold()的效果是等价的。

为什么这一项在 2026 年特别值得提？因为新版 Node LTS 已经普遍跑在 22、24 上，styleText早已不是实验性功能。从维护角度，删掉chalk能少一棵依赖树；从实际体验看，如果你只是想让终端里的错误和信息有点颜色，原生能力完全够。

当然，chalk在复杂场景依然有优势：模板字符串、256 色/真彩色支持、链式嵌套、自动检测 TTY 等。如果你的 CLI 工具要做非常复杂的交互式输出，保留chalk没问题。但对于应用项目里的“log 红一下绿一下”，styleText已经足够了。

3. 迁移实操：如何安全地从 package.json 里移除这些包

3.1 迁移前的依赖核查清单

不管替换方案多简单，直接npm uninstall都可能出问题。我在动手之前会先做一次“依赖体检”，主要看三件事。

第一，直接依赖和传递依赖。用npm ls axios dotenv rimraf uuid chalk可以看到这些包到底在依赖树里出现在哪里。如果某个包只是作为传递依赖被别的包引入，而你直接卸载根目录的包，不一定能让依赖树变干净。我们要删除的是“我们自己在代码里import的那个”。

第二，代码里的引用点。只靠搜索关键词可能漏掉。我习惯先用grep -r "from 'axios'" src/批量查一遍，再顺手看下npm ls --depth=0。如果项目里有axios封装文件，迁移后会失效，提前标记出来。

第三，npm scripts 里的命令。很多工具依赖并不是写死在代码里，而是在package.json的 scripts 里使用，比如rimraf dist、dotenv -e .env node ...。这类引用光搜import搜不到，要重点检查 scripts 字段。

3.2 分模块替换，而不是一键删除

我的建议是：一次只替换一个包，提交一次，跑一遍测试，再继续下一个。不要上午把所有包换完，下午项目跑不起来了才发现不知道哪个改动出问题。

具体顺序可以是：先换uuid，因为它最简单，搜出所有uuid.v4()，改成randomUUID()，测试，删除。再换rimraf，改 scripts，测试。接着换dotenv，改启动参数。最后处理axios和chalk，因为这两个可能涉及代码逻辑，需要多跑几轮回归。

替换代码时不要怕改动多。例如把 axios 全局实例替换成自己封装的时候，原来request.get('/api/user')这种调用可能需要改成request('/api/user')。如果项目里有很多页面都引用了 axios 实例，建议先封装一层兼容函数，而不是让所有调用点一次性改完。

3.3 CI/CD 与锁文件处理

迁移不只是改本地代码。CI/CD 里的 Dockerfile 或工作流脚本如果直接跑npm run build，通常没问题；但如果你在 CI 里用了类似npx rimraf的命令，或者显式安装了dotenv-cli，那也要一起改。

删除包之后一定要重新生成锁文件：

npm uninstall axios dotenv rimraf uuid chalk npm install

或者手动编辑package.json后执行npm install，让package-lock.json同步更新。如果不重新生成锁文件，别人拉代码执行npm ci时可能会报 lock 文件和 package.json 不匹配。

提交后最好做一次干净环境验证：删掉整个node_modules，用npm ci重新安装，然后跑一遍npm run build && npm test。这一步能确认项目真正摆脱了这几个包。

4. 常见问题与排查技巧实录

4.1 版本与兼容性速查表

迁移时最常遇到的问题是“我的 Node 版本到底够不够”。下面这张表建议直接收藏：

如果你的项目还在维护 Node 16 或更老的版本，那确实不建议强行迁移，先升 Node 再说。2026 年还跑在 Node 16 上，本身的安全风险比依赖包更大。

4.2 工作区里还有“幽灵依赖”

一个很容易被忽略的情况是：你把axios从项目的直接依赖里删了，但项目里的某个子包或 scripts 还在使用它，而且因为 Node 的node_modules扁平化结构，代码依然能跑起来。这种“幽灵依赖”特别坑，因为本地能跑不代表新环境下还能跑。

解决办法是删包之前先尽量找出所有引用点，删包之后用npm ls axios确认依赖树里已经没有任何相关包。如果只是留在锁文件里的传递依赖，可以视情况通过npm dedupe或升级父依赖来处理。

4.3npm : 无法加载文件 ... npm.ps1这类报错要不要管

这个话题虽然不直接是“删包”的问题，但确实和 npm 环境有关。Windows 上运行npm命令如果报无法加载文件 ...npm.ps1，因为在此系统上禁止运行脚本，通常不是 npm 本身坏了，而是 PowerShell 执行策略限制。

解决方式很简单：以管理员身份打开 PowerShell，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

然后再执行npm命令。这个操作和本文的迁移无关，但如果你的团队里有同事在做完npm uninstall后遇到类似的 PowerShell 脚本问题，可以顺手提醒一句。

4.4 实用避坑心得

除了技术细节，还有几个我踩过坑的经验值得分享。

不要为了“删包”而删包。原生fetch虽然好用，但 axios 还有取消请求、上传进度、拦截器等成熟 API。如果项目里大量依赖这些高级能力，强行换成 fetch 封装会让代码变得复杂。我更推荐新项目直接用原生能力，老项目则按模块逐步迁移。

删包后要更新团队的开发习惯。项目里少了dotenv，新同事可能还会习惯性地写下import 'dotenv/config'。建议在项目 README 的“开发环境”部分写清楚启动命令是node --env-file=.env ...，让所有人保持一致。

要注意依赖瘦身不是一劳永逸。你把axios删了，过段时间换个新功能又有人安装一个类似库，这是常态。我的做法是在 PR 模板里加一项“是否真的需要新增依赖”，提醒自己和团队先想想标准库能不能解决。

写在最后

说实话，我第一次看到 Node 内置fetch、内置styleText、内置loadEnvFile的时候，第一反应是“那我以前安装的那些包算什么”。后来想明白了：第三方包的作用本来就是填补生态空白。当原生 API 补上来了，我们作为开发者，也应该适时把维护成本卸下来。

我个人在实际操作中的体会是：删包最难的不是写替代代码，而是改变团队的习惯。我现在的新项目模板已经是零axios、零dotenv、零rimraf、零uuid、零chalk了。每次有同事准备npm i axios的时候，我会让他先写一个 fetch 小封装，5 分钟搞定，之后他就再也没回头。2026 年的 JavaScript 生态已经足够强大，给你的项目做一次减负，收益远比想象中明显。