张磊盯着监控屏幕上飙升的加载时间，冷汗顺着后背滑下。作为电商平台的前端负责人，他清楚知道页面每多加载 1 秒，转化率就会下跌 7%。而此刻生产环境的 bundle.js 体积比昨天突然增加了 2.3MB，这意味着至少有数千用户正在经历卡顿甚至白屏。

"把 node_modules 删了重新 install！" 实习生小王脱口而出的建议让张磊皱紧了眉头。这个在开发环境屡试不爽的 "万能解法"，在四小时前的生产发布中，恰恰成了引爆问题的导火索。

依赖分类的平行宇宙

打开任何前端项目的根目录，package.json 文件就像个神秘的潘多拉魔盒。大多数开发者只关心 dependencies 和 devDependencies 这两个长得很像的字段，却很少有人真正理解它们之间的平行宇宙关系。

npm 官方文档明确指出：dependencies 是项目在生产环境中运行所依赖的包，而 devDependencies 仅用于开发和测试阶段。这个区别直接决定了依赖是否会被 webpack 打包进入生产环境。

正确的配置应该像这样：

左侧标注 "我的模块工作必要的依赖" 的 dependencies，就像厨房必备的锅碗瓢盆，少了它们整个项目根本无法运行。而右侧 "仅在开发任务中需要的依赖"devDependencies，则更像是厨师的品尝勺 —— 烹饪时不可或缺，但绝不会出现在最终的菜品里。

当开发依赖 "偷渡" 到生产环境

现代前端工程化流程中，webpack 就像个严格的海关检查员。它会根据依赖类型决定哪些模块允许进入生产环境的 "国境线"。张磊团队的问题就出在把 babel-loader 这个仅用于代码转译的开发依赖，错误地安装到了 dependencies 中。

无独有偶，2025 年 5 月，Sarus 项目团队发现 jest-environment-jsdom 被错误地列为生产依赖，导致用户安装时会不必要地下载测试相关的大量依赖包。他们通过将其从 dependencies 移动到 devDependencies，并发布新版本 (0.5.0) 解决了这个问题。这一变更带来了显著的改进：实现了零生产依赖，用户安装体积减小，构建产物的第三方许可证声明更加精简准确。

要避免这类问题，定期执行npm ls --prod命令审计依赖树是个好习惯。这个命令会显示所有生产环境依赖，任何不属于生产环境的依赖都会清晰显示。

三步建立依赖防火墙

1. 建立依赖分类清单

在项目初始化阶段就明确划分依赖类型：

• 生产依赖：react、vue 等运行时必须的库
• 开发依赖：eslint、jest 等辅助开发的工具

安装时务必使用正确的命令：

bash

# 生产依赖
npm install react --save

# 开发依赖
npm install eslint --save-dev

2. 使用 npm ls 命令审计依赖树

定期执行npm ls --prod检查生产依赖树，任何不属于生产环境的依赖都会清晰显示。就像张磊后来发现的，babel-loader 被意外提升为生产依赖，正是因为某个同事执行了npm install babel-loader却忘记添加--save-dev参数。

3. 配置 webpack 的 externals

对于通过 CDN 引入的库，在 webpack.config.js 中配置：

javascript

module.exports = {
  externals: {
    jquery: 'jQuery'
  }
}

这相当于给依赖装上了 "免检通行证"，既减小包体积又避免重复加载。

从事故到规范：张磊团队的救赎

事故发生后的复盘会上，团队制定了三条铁律：所有依赖安装必须显式添加 --save 或 --save-dev；提交 package.json 前必须执行 npm ls 检查；CI 流程增加依赖类型校验。三个月后，他们的生产包体积减少了 42%，首屏加载时间从 3.2 秒优化到 1.1 秒。

在依赖管理这个看似微小的细节背后，藏着前端工程化的核心哲学：每一行配置都应该有其存在的理由，就像每一个依赖都应该待在它该去的地方。在前端开发的世界里，真正的高手不仅能写出优雅的代码，更懂得如何管理那些看不见的依赖关系。