西瓜视频手机版
81.45MB · 2025-11-06
autoclean斩断 “垃圾文件”在现代前端开发中，当你执行npm install后看到 node_modules 文件夹膨胀到 1.5GB 时，不必惊讶 —— 这已是常态。但对于 Umi 框架项目而言，这个 "体积怪兽" 不仅吞噬磁盘空间，更会导致开发启动缓慢、构建时长增加、部署包体积飙升等一系列问题。本文将基于 Umi 框架特性，提供一套可落地的完整优化方案，从分析到执行，一步步将 node_modules 体积控制在合理范围。
graph TD
A[node_modules臃肿] -->| 安装analytics分析插件 | B(查看包体积分布情况)
B --> C[解决方案]
C --> | 安装depcheck |D[剔除无用的插件]
C --> E[依赖替换计划]
C --> F[umi内置优化]
C --> G[依赖管理升级]
C --> |autoclean|H[删除无用空文件]
C --> I[持续维护]
在优化之前，我们需要精准定位问题 —— 哪些依赖在 "作恶"？Umi 项目可通过以下工具组合进行全面体检。
# 全局安装核心分析工具
npm install -g depcheck
# 在项目根目录执行
depcheck
该命令会输出三类关键信息：
Unused dependencies
├── lodash # 生产依赖中未使用
└── moment # 生产依赖中未使用
Unused devDependencies
├── eslint-plugin-vue # 开发依赖中未使用
└── webpack-cli # 开发依赖中未使用
Missing dependencies
└── axios # 代码中使用了，但未在package.json声明
depcheck介绍depcheck并非简单 “字符串匹配”，而是通过AST 语法分析 + 依赖图谱构建实现精准检测，核心步骤分 3 步：
package.json中的dependencies/devDependencies，生成 “已声明依赖列表”；同时遍历项目源码目录（默认排除node_modules/dist等目录），记录所有通过import/require引入的 “实际使用依赖列表”。.js/.ts/.jsx等源码文件构建抽象语法树（AST），提取ImportDeclaration（ES 模块）、CallExpression（CommonJS 模块）中的依赖标识符（如import lodash from 'lodash'中的lodash），排除 “仅声明未调用” 的依赖（如代码中import moment from 'moment'但未使用moment变量）。package.json声明的依赖；eslint仅在开发阶段调用，若出现在dependencies中则提示分类错误）。analyze 介绍Umi 框架内置的体积分析配置（即 analyze 配置项）本质上是对 Webpack 生态中 webpack-bundle-analyzer 插件的封装，通过自动化配置简化了开发者手动集成该插件的流程，最终实现对项目打包体积的可视化分析。
原理解析
底层依赖：webpack-bundle-analyzer
Umi 基于 Webpack 构建，而 webpack-bundle-analyzer 是 Webpack 生态中最常用的体积分析工具。它的工作原理是：
dist 目录下的 JS/CSS 文件）和对应的 sourcemap（用于映射打包代码与原始源码）。chunk（打包后的代码块）的体积、内部包含的模块（如第三方依赖、业务代码）及其体积占比。Umi 内置配置的封装逻辑
Umi 的 analyze 配置并非重新实现体积分析功能，而是通过框架层自动处理了 webpack-bundle-analyzer 的集成细节，具体包括：
条件性引入插件
当开发者在 Umi 配置文件（config/config.ts 或 .umirc.ts）中开启 analyze: { ... } 时，Umi 会在 Webpack 配置阶段自动引入 webpack-bundle-analyzer 插件，并将用户配置的参数（如 analyzerPort、openAnalyzer 等）传递给该插件。
例如，用户修改 Umi 配置文件（config/config.ts 或 .umirc.ts）：
import { defineConfig } from 'umi';
export default defineConfig({
analyze: {
analyzerMode: 'server', // 分析模式 server本地服务器 static 静态html文件 disabled禁用分析
analyzerPort: 8888, // 端口
openAnalyzer: true, // 是否自动在浏览器中打开
generateStatsFile: false, // 是否生成统计文件
statsFilename: 'stats.json', // 文件名称
logLevel: 'info', // 日志等级
defaultSizes: 'parsed', // stat // gzip // 显示文件大小的计算方式
},
}
Umi 会将其转化为 Webpack 插件配置：
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: 'server', // 启动本地服务展示报告
analyzerPort: 8888, // 服务端口
openAnalyzer: true, // 构建后自动打开浏览器
}),
],
};
与 Umi 构建流程联动Umi 的构建命令（umi build）会触发 Webpack 的打包过程。当 analyze 配置开启时，Webpack 在打包完成后会执行 webpack-bundle-analyzer 的逻辑：
启动一个本地 HTTP 服务（默认端口 8888），将分析结果以 HTML 页面的形式展示。
自动打开浏览器访问该服务，开发者可直观查看体积分析报告
analyze 配置提供了合理的默认值（如默认 analyzerMode: 'server'、openAnalyzer: true），无需开发者手动配置即可快速使用，降低了使用门槛。数据来源：Webpack 打包过程中会生成 stats 对象（包含构建过程的详细信息，如模块依赖、chunk 组成、体积等），webpack-bundle-analyzer 通过解析该对象获取基础数据。
体积计算：报告中展示的体积通常是未压缩的原始体积（便于分析模块真实占比），但也会标注 gzip 压缩后的体积（更接近生产环境实际传输大小）。
可视化呈现：通过树状图（每个节点代表一个模块或 chunk，大小与体积成正比）和列表（按体积排序）展示，支持点击节点查看子模块细节。
stats对象拆解以及体积计算规则
stats 对象的核心数据结构：Webpack 构建时会生成包含 “模块依赖树” 的stats对象，关键字段包括：- modules：所有参与构建的模块（含业务代码、第三方依赖），每个模块记录id（唯一标识）、size（原始体积）、dependencies（子依赖列表）、resource（文件路径）；
chunks：打包后的代码块，每个 chunk 记录id、modules（包含的模块 ID 列表）、size（chunk 原始体积）、gzipSize（gzip 压缩后体积）；
assets：最终输出的静态资源（如main.xx.js），关联对应的 chunk 及体积。
体积计算的两个维度：- 原始体积（parsed size）：模块经过 Webpack 解析（如 babel 转译、loader 处理）后的未压缩体积，反映 “模块真实占用的内存空间”，用于定位 “大体积模块根源”；
analyze报告中的 “重复依赖体积”，是通过比对不同 chunk 中modules的resource路径（如node_modules/lodash/lodash.js在两个 chunk 中均出现），累加重复模块的体积得出。Umi 内置的体积分析配置本质是对 webpack-bundle-analyzer 插件的 “零配置” 封装，通过框架层自动处理插件引入、参数传递和构建流程联动，让开发者无需关心 Webpack 底层细节，仅通过简单配置即可快速生成项目体积分析报告，从而定位大体积依赖、冗余代码等问题，为性能优化提供依据。
# 启动分析（需要配置环境变量）
ANALYZE=1 umi dev
# 构建分析（需要配置环境变量）
ANALYZE=1 umi build
在分析页面中，你可以：
经过分析后，首先要做的就是 "减肥"—— 移除不必要的依赖，这是最直接有效的优化手段。
根据depcheck的输出结果，执行卸载命令：
# 卸载未使用的生产依赖
npm uninstall <package-name>
# 卸载未使用的开发依赖
npm uninstall --save-dev <package-name>
清理 “未声明但已安装” 的依赖（防止误删）：
npm prune # 仅保留package.json中声明的依赖
注意事项：
卸载前先在代码中搜索确认该依赖确实未被使用
对于不确定的依赖，可先移至 devDependencies 观察一段时间
团队协作项目需同步更新 package-lock.json 或 yarn.lock
确保依赖类型划分正确，避免开发依赖混入生产依赖：
{
"dependencies": {
// 仅包含运行时必需的依赖
"react": "^18.2.0",
"react-dom": "^18.2.0",
"dayjs": "^1.11.7" // 运行时需要的日期处理库
},
"devDependencies": {
// 开发和构建时需要的工具
"@umijs/preset-react": "^2.9.0",
"@types/react": "^18.0.26",
"eslint": "^8.30.0", // 仅开发时使用的代码检查工具
"umi": "^3.5.40"
}
}
moment：默认包含所有地区的语言包（如locale/zh-cn.js、locale/en-gb.js），即使项目仅用 “日期格式化” 功能，也会打包全部语言包（占总体积的 40% 以上）；
lodash（全量包）：包含 100 + 工具函数，项目若仅用debounce/throttle，仍会打包其余 90% 未使用函数，属于 “按需加载缺失” 导致的冗余。[email protected]前版本）为兼容 IE 浏览器，会内置Promise/Array.prototype.includes等 ES6+API 的 polyfill（如core-js代码），而现代前端项目（如基于 Umi 3+）已通过browserslist指定 “不兼容 IE”，这些 polyfill 成为无效冗余代码，占体积 15%-20%。axios为例，其依赖follow-redirects（处理重定向），而follow-redirects又依赖debug（日志工具），debug再依赖ms（时间格式化）—— 这种 “依赖链过长” 导致 “间接依赖体积累加”，且若其他依赖也依赖debug的不同版本，会引发 “版本分叉”（如[email protected]和[email protected]同时存在）。
针对 Umi 项目常用的大型依赖，推荐以下轻量替代方案：| 功能场景 | 传统重量级依赖 | 推荐轻量替代 | 体积减少 | 替换难度 |
|---|---|---|---|---|
| 日期处理 | moment(240kB) | dayjs(7kB) | 97% | 低 |
| 工具库 | lodash(248kB) | lodash-es (按需加载) | 90%+ | 中 |
| HTTP 客户端 | axios(142kB) | ky(4.8kB) | 95% | 中 |
| 状态管理 | redux+react-redux(36kB) | zustand(1.5kB) | 95% | 中 |
| 表单处理 | antd-form (含在 antd 中) | react-hook-form(10kB) | 视情况 | 中高 |
| UI 组件库 | antd (完整，~500kB) | antd 按需加载 + lodash-es | 60-80% | 低 |
dayjs：采用 “核心 + 插件” 架构，核心体积仅 7kB（含基础日期处理），语言包、高级功能（如相对时间relativeTime）需手动导入（如import 'dayjs/locale/zh-cn'），避免 “全量打包”；
lodash-es：基于 ES 模块（ESM）设计，支持 “树摇（Tree Shaking）”—— Webpack/Rollup 会自动剔除未使用的函数（如import { debounce } from 'lodash-es'，仅打包debounce相关代码），而传统lodash（CommonJS 模块）因 “函数挂载在全局对象”（如_ = require('lodash')），无法被 Tree Shaking 优化。ky（替代axios）仅支持 ES6 + 环境，直接使用原生fetch API（无需内置Promise polyfill），且移除axios中 “过时功能”（如transformRequest的兼容处理），体积从 142kB 降至 4.8kB，核心是 “放弃旧环境兼容，聚焦现代浏览器”。zustand（替代redux+react-redux）无任何第三方依赖，核心逻辑仅 1.5kB，而redux依赖loose-envify（环境变量处理）、react-redux依赖hoist-non-react-statics（组件静态属性提升），间接依赖体积累加导致总大小达 36kB—— 轻量依赖的 “零依赖 / 少依赖” 设计，从根源减少 “依赖嵌套冗余”。替换实操示例（moment → dayjs）：
卸载旧依赖：
npm uninstall moment
安装新依赖：
npm install dayjs --save
代码替换（批量替换可使用 IDE 全局替换功能）：
// 旧代码
import moment from 'moment';
moment().format('YYYY-MM-DD');
// 新代码 import dayjs from 'dayjs'; dayjs().format('YYYY-MM-DD');
效果：中小型项目可减少 10%-30% 的体积，尤其适合历史项目的 “首次瘦身”。
## 三、Umi 专属优化：框架特性深度利用
Umi 框架内置了多项优化能力，充分利用这些特性可显著减少依赖体积。
### 3.1 路由级懒加载配置
Umi 的路由系统默认支持懒加载，只需正确配置路由即可实现按路由分割代码：
```js
export default [
{
path: '/',
component: '../layouts/BasicLayout',
routes: [
{
path: '/',
name: '首页',
component: './Home'
},
{
path: '/dashboard',
name: '数据看板',
component: './Dashboard',
// 可配置更精细的分割策略
// 仅在访问该路由时才加载echarts
chunkGroup: 'dashboard'
},
{
path: '/analysis',
name: '深度分析',
component: './Analysis',
// 大型页面单独分割
chunkGroup: 'analysis'
},
{
path: '/setting',
name: '系统设置',
component: './Setting'
}
]
}
];
优化效果：访问首页时仅加载首页所需依赖，不会加载 dashboard 所需的 echarts 等重型库
对于页面内的大型组件（如富文本编辑器、图表组件），使用 Umi 的dynamic方法实现按需加载：
import { dynamic, useState } from 'umi';
import { Button } from 'antd';
// 动态导入ECharts组件（仅在需要时加载）
const EChartComponent = dynamic({
loader: () => import('@/components/EChartComponent'),
// 加载状态提示
loading: () => <div className="loading">图表加载中...</div>,
// 延迟加载，避免快速切换导致的不必要加载
delay: 200,
});
// 动态导入数据导出组件（仅在点击按钮时加载）
const DataExportComponent = dynamic({
loader: () => import('@/components/DataExportComponent'),
loading: () => <div className="loading">准备导出工具...</div>,
});
export default function Dashboard() {
const [showExport, setShowExport] = useState(false);
return (
<div className="dashboard">
<h1>数据看板</h1>
{/* 图表组件会在页面加载时开始加载 */}
<EChartComponent />
<Button onClick={() => setShowExport(true)}>
导出数据
</Button>
{/* 导出组件仅在点击按钮后才会加载 */}
{showExport && <DataExportComponent />}
</div>
);
}
import { defineConfig } from 'umi';
export default defineConfig({
// 配置外部依赖
externals: {
// 键：包名，值：全局变量名
react: 'window.React',
'react-dom': 'window.ReactDOM',
'react-router': 'window.ReactRouter',
lodash: 'window._',
echarts: 'window.echarts',
},
// 配置CDN链接（生产环境）
scripts: [
'https://cdn.jsdelivr.net/npm/[email protected]/umd/react.production.min.js',
'https://cdn.jsdelivr.net/npm/[email protected]/umd/react-dom.production.min.js',
'https://cdn.jsdelivr.net/npm/[email protected]/umd/react-router.min.js',
'https://cdn.jsdelivr.net/npm/[email protected]/lodash.min.js',
'https://cdn.jsdelivr.net/npm/[email protected]/dist/echarts.min.js',
],
// 开发环境仍使用本地依赖，避免CDN不稳定
define: {
'process.env.NODE_ENV': process.env.NODE_ENV,
},
// 条件性加载CDN
headScripts: process.env.NODE_ENV === 'production' ? [
// 生产环境额外的CDN脚本
] : [],
});
注意：配置 externals 后需确保代码中不再通过import引入这些库
Umi 配合@umijs/plugin-antd可实现 Ant Design 的按需加载
import { defineConfig } from 'umi';
export default defineConfig({
antd: {
// 启用按需加载
import: true,
// 配置主题，减少不必要的样式生成
theme: {
'primary-color': '#1890ff',
'link-color': '#1890ff',
'success-color': '#52c41a',
// 只保留必要的主题变量，减少css体积
},
},
// 配置babel-plugin-import优化其他组件库
extraBabelPlugins: [
[
'import',
{
libraryName: 'lodash',
libraryDirectory: '',
camel2DashComponentName: false,
},
'lodash',
],
[
'import',
{
libraryName: '@ant-design/icons',
libraryDirectory: 'es/icons',
camel2DashComponentName: false,
},
'antd-icons',
],
],
});
npm/yarn 的 “嵌套依赖” 机制是根源之一。例如：
项目依赖[email protected]，而A又依赖[email protected]；
同时项目依赖[email protected]，C又依赖[email protected]；
此时 node_modules 中会同时存在[email protected]和[email protected]，即使两者差异极小，也会重复占用空间。
对于复杂项目，这种 “版本分叉” 会呈指数级增长，最终导致大量重复代码堆积。
Umi 项目迁移步骤如下（3分钟搞定）：
# 安装pnpm
npm install -g pnpm
# 验证安装
pnpm --version
# 删除现有node_modules
rm -rf node_modules
# 删除锁文件
rm -f package-lock.json yarn.lock
# 安装依赖（会生成pnpm-lock.yaml）
pnpm install
# 验证安装结果
pnpm ls
pnpm需要至少Node.js v18.12的版本才能正常运行。所以实际项目中有的node版本可能是18以下，这里来教大家怎么升级
pnpm run start
node:internal/crypto/hash:69
this[kHandle] = new _Hash(algorithm, xofLen);
^
Error: error:0308010C:digital envelope routines::unsupported
常发生在使用较新的 Node.js 版本（如 v18+）运行一些基于 Webpack 4 或更早版本构建的项目时，原因是 Node.js 升级后对 OpenSSL 加密算法的支持发生了变化，导致旧版构建工具不兼容。
临时设置环境变量（最简单，推荐测试用） Windows（cmd 命令行）：
set NODE_OPTIONS=--openssl-legacy-provider && npm start
Windows（PowerShell）：
$env:NODE_OPTIONS="--openssl-legacy-provider" && npm start
Mac/Linux（终端）：
NODE_OPTIONS=--openssl-legacy-provider npm start
降低node版本
nvm ls
nvm install
nvm use
使用nvm直接降级即可
升级umi4.x
autoclean斩断 “垃圾文件”核心目标：移除依赖中的测试、文档、日志等无用文件。
工具：yarn 自带的autoclean或 npm 生态的modclean。
以npm modclean（更轻量，无需额外安装）：
安装modclean：
npm install modclean -g
执行清理（默认清理常见无用文件，支持自定义规则）：
modclean -n default -o # -n：规则集，-o：删除空文件夹
注意不同的modclean版本配置不一样
modclean3.x版本可直接运行上面命令，2.x版本需要配置文件
步骤 1：创建配置文件（.modcleanrc）添加 empty: true 配置（作用等同于 -o 参数）：
{
"empty": true, // 启用：清理后自动删除空文件夹
"rules": {
"default": { // 复用默认规则集（等同于命令行 -n default）
"include": [
"**/__tests__/**",
"**/test/**",
"**/docs/**",
"**/examples/**",
"**/*.log",
"**/*.md",
"**/.gitignore"
]
}
},
"defaultRule": "default" // 默认使用上述规则集
}
步骤 2：执行清理命令
modclean -c .modcleanrc # -c 指定配置文件路径
验证效果 查看 node_modules 中是否存在空文件夹（Mac/Linux）
find ./node_modules -type d -empty
Windows 系统（PowerShell）：
Get-ChildItem -Path ./node_modules -Directory -Recurse | Where-Object { $_.GetFiles().Count -eq 0 -and $_.GetDirectories().Count -eq 0 }
理想结果：执行后无任何输出，说明所有空文件夹已被删除； 效果：单个依赖的体积可减少大概40% ，例如lodash清理后从 2MB 降至 1.2MB，axios从 1.5MB 降至 0.9MB。
优化后若不维护，node_modules 可能再次膨胀，需建立 3 个习惯：
package-lock.json（npm）或yarn.lock（yarn），避免安装时自动升级到高版本（可能引入冗余依赖）。npm outdated或yarn outdated查看过时依赖，优先更新体积小、无破坏性变更的包（避免因依赖过旧导致兼容性问题，间接增加依赖体积）。bundlephobia查询新依赖的体积，拒绝 “大而全” 但仅用少量功能的包（如仅用lodash的debounce，则直接引入lodash.debounce而非全量lodash）。bundlephobia 能快速查询依赖体积，核心是 “云端模拟 Webpack 构建 + 体积分析”，步骤如下：
依赖下载与构建：
当查询lodash时，bundlephobia 会从 npm 仓库下载lodash的最新版本，通过 “模拟 Webpack+Tree Shaking” 构建（默认配置mode: production、optimization.usedExports: true），生成 “全量导入”（import _ from 'lodash'）和 “按需导入”（import { debounce } from 'lodash'）两种场景的构建产物。
体积计算与对比：- 原始体积：构建产物的未压缩大小（对应 Webpack 的parsed size）；
gzip（默认压缩级别 6）和brotli（更高效的压缩算法）计算的体积；axios的 142kB 包含follow-redirects等子依赖的体积）。版本对比功能：
记录该依赖历史版本的体积变化（如[email protected]到[email protected]的体积是否增加），并标注 “体积突变版本”（如某版本引入新子依赖导致体积暴涨）—— 帮助用户选择 “体积稳定的版本”。
核心工具为size-limit（基于 Webpack 的体积检测工具）：
size-limit 的工作原理：- 配置文件（.size-limit.json）中指定 “需要监控的入口文件”（如src/index.js）和 “体积阈值”（如100kB）；
size-limit时，工具会模拟生产环境构建（使用 Webpack/Rollup），计算入口文件对应的 chunk 体积；与 Git 钩子的集成：
通过husky配置pre-commit钩子，每次提交代码前自动运行size-limit，若新增依赖导致体积超标，禁止提交 —— 原理是 “在代码提交阶段提前拦截问题，避免等到构建时才发现”。
体积变化报告生成：
集成size-limit --json输出体积变化数据，结合github-action-size等工具，在 PR（Pull Request）中自动生成 “体积对比报告”（如 “本次 PR 新增依赖导致体积增加 15kB”），让团队直观看到 “依赖变更的体积影响”。
| 指标 | 初始状态 | 优化后状态 | 优化幅度 |
|---|---|---|---|
| node_modules 体积 | 1.5GB | 996MB | 减少35.5% |
| 依赖安装时间 | 1分钟 | 26.6秒 | 减少50.8% |
| 项目构建时间 | 2分38秒 | 1分20秒 | 减少57.5% |
node_modules 体积膨胀是现代 JavaScript 开发中的普遍问题，但通过系统的分析和有针对性的优化，我们完全可以驯服这个 "体积怪兽"。从精简依赖清单到选择轻量替代品，从使用现代包管理器到构建优化，每一步都能带来显著的改善。 记住，控制 node_modules 体积是一个持续的过程，需要团队共同努力和长期坚持。通过建立良好的依赖管理习惯和自动化监控机制，我们可以保持项目的轻盈和高效，让开发体验更加流畅。 最后，每引入一个新依赖，都应该深思熟虑，因为每一行不需要的代码，都是未来的技术债务。
作者：洞窝-佳宇
