前端小白别硬扛：打包和代码分割救命指南，加载快3倍老板当场加薪

前端小白别硬扛：打包和代码分割救命指南，加载快3倍老板当场加薪

• 前端小白别硬扛：打包和代码分割救命指南，加载快3倍老板当场加薪
• • 聊聊那个让用户等到想砸手机的白屏时刻
  • 打包到底是啥？快递小哥都懂的道理
  • 代码分割：别一次性把家当全搬出来
  • 打包那点事儿：好处多但坑也不少
  • 实战：从后台管理到电商大促
  • • 场景一：后台管理系统的路由懒加载
    • 场景二：电商大促页面的组件级分割
    • 公共库缓存策略：让老用户飞起来
    • 那个"真香"配置：自动分割不用愁
  • 踩坑实录：那些年我修过的 bug
  • • 坑一：打包后体积反而变大了？
    • 坑二：代码分割了但浏览器报错"找不到模块"
    • 坑三：生产环境能跑，本地开发就挂
    • 坑四：循环依赖导致打包卡死或分割失效
  • 开发技巧：从及格到优秀
  • • 别迷信默认配置
    • 魔法注释：给 chunk 起个好名字
    • Preload 和 Prefetch：别让浏览器做无用功
    • Module Federation：微前端的高级玩法
  • 最后那点碎碎念

前端小白别硬扛：打包和代码分割救命指南，加载快3倍老板当场加薪

聊聊那个让用户等到想砸手机的白屏时刻

说实话，每次上线前我都有种奇怪的感觉，就像小时候考完试等成绩，明知道可能有问题，但还抱着侥幸心理。直到用户开始在群里炸锅：“这破网站怎么一直转圈圈？”、“我流量都用了200M了还没进去？”——这时候你就知道，那个 dreaded 的白屏时刻又来了。

最离谱的是啥？是我明明就写了几个页面，功能简单得像个静态网页，结果打包出来一看，好家伙，主包体积 5.8MB。5.8MB 啊朋友们，这体积都快赶上当年 Windows 98 的安装包了。我就纳了闷了，我就写了个 Todo List，怎么感觉把整个操作系统都打包进去了？

后来我才明白，这就是前端开发的魔幻现实主义。你写代码的时候觉得自己在绣花，精雕细琢；打包的时候才发现自己其实在搬砖，而且搬的还是那种实心的大青砖。今天咱们不聊那些虚头八脑的概念，什么"工程化"、"构建优化"这种听着就犯困的词。咱就聊点实在的：怎么让你的网页"嗖"一下打开，让用户不再盯着那个转圈圈的 loading 动画发呆，让老板看着性能报告能笑出声，顺便考虑给你加点薪。

打包到底是啥？快递小哥都懂的道理

我第一次听"打包"这个词的时候，脑子里浮现的是过年回家收拾行李的画面——把所有衣服、充电器、没吃完的零食一股脑塞进箱子，然后发现箱子拉不上拉链了。后来才发现，代码打包还真就是这个理儿。

你想啊，你写的代码，今天一个 utils.js，明天一个 components/Button.jsx，后天又整了个 hooks/useAuth.ts。这些文件散落在项目各个角落，就像你房间里乱扔的衣服。浏览器要是直接去加载，得发几十个 HTTP 请求，每个请求还得建立连接、等待响应，这一套下来，用户早就不耐烦了。

打包工具干的事儿，就是找个快递小哥（也就是 bundler），把这些散乱的文件都收集起来，该合并的合并，该整理的整理，最后塞进一个或几个大箱子里。浏览器只需要搬这几个箱子就行，省事多了。

现在的打包工具圈子也挺有意思的。Webpack 依然是那个稳坐中军帐的老大哥，生态丰富得吓人，啥插件都有，但配置起来也是真的头大，那个配置文件长得能当小说看。Vite 这两年异军突起，开发环境下冷启动快得离谱，简直是"秒开"代言人，生产环境用 Rollup 打包也是又快又稳。还有 Rollup 本身，做库开发的时候简直是神器，打出来的包又干净又小。

不过说实话，工具只是手段，原理搞懂了，换哪个工具都能玩得转。就像你会骑自行车了，换辆电动车照样能上路，就是拧油门和蹬踏板的区别。

代码分割：别一次性把家当全搬出来

打包好是好，但有个致命问题——如果所有代码都打包成一个文件，那用户第一次访问的时候，哪怕只是想看个登录页，也得把整个应用的代码都下载下来。这就好比你去饭店吃饭，只是想点碗面条，结果服务员把整个菜单上的菜都给你端上来了，还说"您慢慢吃，吃不完的打包带走"。这不神经病吗？

代码分割（Code Splitting）就是解决这个问题的。它的核心思想特别简单：用户走到哪间房，再给哪间房的钥匙。没进厨房就别给菜刀，没进卧室就别给枕头。

具体怎么玩呢？最常见的就是按路由切分。你的应用有首页、用户中心、设置页面，那就把这三个页面分别打包成三个文件。用户第一次进来只看首页，那就只加载首页的代码，其他两个页面的代码等用户点过去了再加载。这样一来，首屏加载速度直接起飞。

还有更细的玩法，比如按组件懒加载。那个巨大的图表组件，只有用户滚动到那个区域才加载；那个复杂的富文本编辑器，只有用户点击"编辑"按钮的时候才出现。这种"按需加载"的思路，用专业点的话说叫"Lazy Loading"，听着挺高大上，其实就是"懒一点，别那么勤快"。

最骚的操作是动态 import。以前的 import 都是写在文件顶部的，静态的，打包的时候就确定了。但动态 import 是运行时决定的，你可以根据条件来判断要不要加载某个模块。比如：

// 以前的写法，不管用不用，先打包进来
import HeavyComponent from './HeavyComponent';

// 现在的写法，用的时候再说
const loadHeavyComponent = async () => {
if (userNeedsIt) {
const { default: HeavyComponent } = await import('./HeavyComponent');
return HeavyComponent;
}
};

这种写法在 Webpack 和 Vite 里都支持，打包工具会自动把这个组件单独打成一个文件，不会混在主包里。

说到这儿得提一嘴 Chunk 这个概念。Chunk 就是打包后生成的那些文件，你可以理解为"代码块"。通常我们会把代码分成几种 Chunk：

• Entry Chunk：入口文件，必须有的
• Vendor Chunk：第三方库的代码，比如 React、Vue、Lodash 这些
• Dynamic Chunk：动态加载的代码，就是刚才说的动态 import 生成的

为啥要把第三方库单独拎出来？因为这些库通常更新频率低，但体积大。单独打包后，用户第一次访问缓存了，下次再来的时候直接从缓存读，不用重新下载。要是跟业务代码混在一起，你改个按钮颜色，整个包都变了，缓存就失效了，用户又得重新下载所有代码，亏不亏啊？

打包那点事儿：好处多但坑也不少

打包的好处 obvious，不用多说。兼容性好了，ES6+ 的代码转译成 ES5，老浏览器也能跑；模块管理方便了，不用操心加载顺序；还能做各种优化，压缩、混淆、Tree Shaking 一套组合拳下来，代码体积能小不少。

但坏处也是实打实的。首屏可能变慢，特别是你把所有代码都打成一个包的时候，那个文件体积能吓死人。调试起来也头疼，压缩后的代码看着像天书，得靠 source map 才能找回本来面目，但 source map 本身又占体积，线上环境还得小心别泄露了源码。

Tree Shaking 这招"断舍离"听起来很美好，就是把那些写了但没用的代码像垃圾一样扔掉。比如你引入了 Lodash，但只用了 debounce 一个方法，理想情况下打包工具应该只把 debounce 打包进去，其他的都扔掉。但实际上呢？很多库写得不够"纯粹"，副作用一堆，Tree Shaking 经常摇不干净，最后该打的包一个没少。

代码分割也不是万能药。切得太碎了，文件确实小了，但请求数暴增。HTTP/2 虽然支持多路复用，但请求太多还是会出问题，特别是用户网络不稳定的时候，某个小文件加载失败了，整个页面可能就崩了。我就见过有人为了优化把代码切得七零八落，结果用户用 3G 网络访问的时候，页面加载了一半就卡住了，各种报错，还不如不分割呢。

过度优化真的是个坑。为了追求那几 KB 的体积减少，把代码结构搞得复杂无比，维护成本直线上升。有时候 90 分就够了，非要去追求 100 分，结果头发掉了一把，用户体验也没提升多少。记住，优化是手段，不是目的，别为了优化而优化。

实战：从后台管理到电商大促

光说不练假把式，咱们来看几个真实的场景。

场景一：后台管理系统的路由懒加载

后台管理系统这种项目，页面多得很，仪表盘、用户管理、权限设置、日志审计，几十个页面是常态。如果全打在一个包里，首屏加载能等到用户怀疑人生。

用 React 的话，配合 React Router 这么搞：

import { lazy, Suspense } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';

// 以前的做法，全部静态引入
// import Dashboard from './pages/Dashboard';
// import UserList from './pages/UserList';
// import Settings from './pages/Settings';

// 现在的做法，路由级别的懒加载
const Dashboard = lazy(() => import('./pages/Dashboard'));
const UserList = lazy(() => import('./pages/UserList'));
const Settings = lazy(() => import('./pages/Settings'));

// 搞个 loading 组件，别让用户看白屏
const PageLoading = () => (
<div style={{
display: 'flex',
justifyContent: 'center',
alignItems: 'center',
height: '100vh'
}}>
<Spin size="large" tip="页面加载中，别急…" />
</div>
);

function App() {
return (
<BrowserRouter>
<Suspense fallback={<PageLoading />}>
<Routes>
<Route path="/" element={<Dashboard />} />
<Route path="/users" element={<UserList />} />
<Route path="/settings" element={<Settings />} />
</Routes>
</Suspense>
</BrowserRouter>
);
}

Vue 的话更简单，路由配置里直接写：

// router/index.js
import { createRouter, createWebHistory } from 'vue-router';

const routes = [
{
path: '/',
name: 'Dashboard',
// 箭头函数返回 import，Vue Router 会自动处理懒加载
component: () => import('@/views/Dashboard.vue')
},
{
path: '/users',
name: 'UserList',
component: () => import('@/views/UserList.vue')
},
{
path: '/settings',
name: 'Settings',
component: () => import('@/views/Settings.vue')
}
];

const router = createRouter({
history: createWebHistory(),
routes
});

export default router;

这样一来，用户第一次访问登录页，只加载登录页的代码，其他页面的代码等用户点菜单的时候再加载。首屏速度直接起飞，老板看了都夸你会过日子。

场景二：电商大促页面的组件级分割

电商大促那种页面，功能复杂得很，轮播图、倒计时、库存统计、用户评论，各种组件堆在一起。特别是那个统计图表，可能引用了 ECharts 这种大家伙，如果直接打包进主包，首屏直接爆炸。

这时候就得用组件级别的懒加载了：

import { lazy, Suspense, useState } from 'react';

// 那个巨大的图表组件，单独打包
const HeavyChart = lazy(() => import('./components/HeavyChart'));
// 富文本编辑器，也是个大块头
const RichEditor = lazy(() => import('./components/RichEditor'));

function ProductPage() {
const [showChart, setShowChart] = useState(false);
const [showEditor, setShowEditor] = useState(false);

return (
<div>
{/* 首屏必须的内容，直接加载 */}
<ProductInfo />
<BuyButton />

{/* 统计图表，用户滚动到这儿或者点击按钮才加载 */}
<button onClick={() => setShowChart(true)}>
查看销售趋势
</button>
{showChart && (
<Suspense fallback={<div>图表加载中…</div>}>
<HeavyChart />
</Suspense>
)}

{/* 评价编辑，点击"写评价"才加载编辑器 */}
<button onClick={() => setShowEditor(true)}>
写评价
</button>
{showEditor && (
<Suspense fallback={<div>编辑器加载中…</div>}>
<RichEditor />
</Suspense>
)}
</div>
);
}

Vue 里用异步组件也是类似的思路：

<template>
<div>
<ProductInfo />

<button @click="showChart = true">查看销售趋势</button>
<!– 异步组件，用 Suspense 包裹 –>
<Suspense v-if="showChart">
<template #default>
<HeavyChart />
</template>
<template #fallback>
<div>图表加载中，稍等…</div>
</template>
</Suspense>
</div>
</template>

<script setup>
import { ref, defineAsyncComponent } from 'vue';
import ProductInfo from './ProductInfo.vue';

// defineAsyncComponent 定义异步组件
const HeavyChart = defineAsyncComponent(() =>
import('./components/HeavyChart.vue')
);

const showChart = ref(false);
</script>

公共库缓存策略：让老用户飞起来

React、Vue、Lodash 这些第三方库，更新频率低但体积大，特别适合做长期缓存。关键是怎么让浏览器知道"这个文件我可以一直用，不用重新下载"。

在 Webpack 里，可以通过配置 output.filename 和 optimization.splitChunks 来实现：

// webpack.config.js
module.exports = {
entry: './src/index.js',
output: {
// 给文件加上 content hash，内容变了 hash 才变
filename: '[name].[contenthash:8].js',
path: path.resolve(__dirname, 'dist'),
clean: true, // 清理旧文件
},
optimization: {
splitChunks: {
chunks: 'all', // 对所有模块都进行分割
cacheGroups: {
// 把 node_modules 里的代码单独打包
vendor: {
test: /[\\\\/]node_modules[\\\\/]/,
name: 'vendors',
chunks: 'all',
// 优先级，越高越先匹配
priority: 10,
},
// 公共代码提取
common: {
minChunks: 2, // 至少被两个 chunk 引用才提取
chunks: 'all',
enforce: true,
},
},
},
// 运行时代码单独打包，避免缓存失效
runtimeChunk: 'single',
},
};

这样配置后，打出来的文件大概长这样：

dist/
main.a1b2c3d4.js # 业务代码，你改代码这个会变
vendors.e5f6g7h8.js # 第三方库，你没升级依赖这个就不变
runtime.i9j0k1l2.js # Webpack 运行时代码

配合 Nginx 或者 CDN 的缓存策略，给 vendors 文件设置一年的长期缓存，用户第二次访问的时候，这些文件直接从本地缓存读，速度飞快。

Vite 的话更简单，配置文件里这么写：

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
plugins: [react()],
build: {
rollupOptions: {
output: {
// 手动指定代码分割策略
manualChunks: {
// 把 react 相关打在一起
'react-vendor': ['react', 'react-dom'],
// 把工具库打在一起
'utils': ['lodash-es', 'dayjs'],
},
// 入口文件命名
entryFileNames: 'js/[name]-[hash].js',
// chunk 文件命名
chunkFileNames: 'js/[name]-[hash].js',
// 资源文件命名
assetFileNames: (assetInfo) => {
const info = assetInfo.name.split('.');
const ext = info[info.length – 1];
return `assets/[name]-[hash][extname]`;
},
},
},
},
});

那个"真香"配置：自动分割不用愁

手动配置代码分割太麻烦了，每个项目都写一遍人要疯。其实 Webpack 和 Vite 都提供了比较智能的默认配置，稍微调调就能用。

Webpack 的 splitChunks 默认配置其实已经挺智能了，但有时候需要根据实际情况调整。比如你发现 vendors 文件太大了，可以按体积再细分：

// webpack.config.js
optimization: {
splitChunks: {
chunks: 'all',
maxInitialRequests: 25, // 最大并行请求数，别太多
minSize: 20000, // 最小分割大小，20KB 以下的不分割
maxSize: 244000, // 最大大小，超过这个会尝试再分割
cacheGroups: {
// 把大的第三方库单独拆出来
react: {
test: /[\\\\/]node_modules[\\\\/](react|react-dom)[\\\\/]/,
name: 'react',
chunks: 'all',
priority: 20,
},
router: {
test: /[\\\\/]node_modules[\\\\/](react-router|react-router-dom)[\\\\/]/,
name: 'router',
chunks: 'all',
priority: 15,
},
// 其他的第三方库
vendors: {
test: /[\\\\/]node_modules[\\\\/]/,
name: 'vendors',
chunks: 'all',
priority: 10,
// 复用已有的 chunk
reuseExistingChunk: true,
},
},
},
},

Vite 用 Rollup 打包，配置更简洁：

// vite.config.js
export default defineConfig({
build: {
rollupOptions: {
output: {
manualChunks(id) {
// 把 node_modules 里的代码单独打包
if (id.includes('node_modules')) {
// 按包名分组，避免单个文件太大
const match = id.match(/node_modules\\/(.*?)\\//);
if (match) {
const packageName = match[1];
// 把 @scope/package 这种也处理一下
return `vendor-${packageName.replace('@', '')}`;
}
}
// 按业务模块分割
if (id.includes('/src/pages/')) {
const match = id.match(/\\/src\\/pages\\/(.*?)\\//);
if (match) {
return `page-${match[1]}`;
}
}
},
},
},
// 代码压缩配置
minify: 'terser',
terserOptions: {
compress: {
drop_console: true, // 去掉 console
drop_debugger: true, // 去掉 debugger
},
},
},
});

这几行配置一上，打包工具自动帮你把代码分得明明白白，不用一个个文件手动配置，香得很。

踩坑实录：那些年我修过的 bug

优化路上坑多得很，我踩过的雷能排成一排。分享几个常见的坑和排查思路，希望能帮你少熬几个夜。

坑一：打包后体积反而变大了？

有时候你做了代码分割，结果发现总体积比原来还大，这是因为分割带来了一些运行时代码和额外的请求开销。怎么排查？得上工具。

Webpack 用 webpack-bundle-analyzer，Vite 用 rollup-plugin-visualizer，这两个插件能生成可视化的包体积分析图，哪个文件占多大一目了然。

Webpack 配置：

// webpack.config.js
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');

module.exports = {
// …其他配置
plugins: [
// 打包后自动打开分析页面
new BundleAnalyzerPlugin({
analyzerMode: 'server', // 或者 'static' 生成静态 HTML 文件
openAnalyzer: true,
}),
],
};

Vite 配置：

// vite.config.js
import { visualizer } from 'rollup-plugin-visualizer';

export default defineConfig({
plugins: [
react(),
// 打包完成后生成 stats.html
visualizer({
open: true, // 自动打开浏览器
gzipSize: true, // 显示 gzip 压缩后的大小
brotliSize: true, // 显示 brotli 压缩后的大小
}),
],
});

跑一遍构建，你会看到一个花花绿绿的图，每个色块代表一个模块，越大说明体积越大。这时候你就能发现，是不是不小心把整个 Lodash 引进来了（用 lodash 而不是 lodash-es），或者是不是某个图片资源巨大无比。找到罪魁祸首，该换按需引入的换按需引入，该压缩的压缩。

坑二：代码分割了但浏览器报错"找不到模块"

这种错误通常出现在动态加载的时候，控制台一片红，看着就心慌。常见原因有几个：

// 错误的写法，Webpack 分析不了
const moduleName = './ComponentA';
const Component = lazy(() => import(moduleName));

// 正确的写法，路径必须是字面量
const ComponentA = lazy(() => import('./ComponentA'));
const ComponentB = lazy(() => import('./ComponentB'));

import { Component } from 'react';

// 错误边界组件
class ErrorBoundary extends Component {
constructor(props) {
super(props);
this.state = { hasError: false, error: null };
}

static getDerivedStateFromError(error) {
return { hasError: true, error };
}

componentDidCatch(error, errorInfo) {
console.error('组件加载出错:', error, errorInfo);
}

render() {
if (this.state.hasError) {
return (
<div>
<h2>哎呀，出错了</h2>
<button onClick={() => window.location.reload()}>
刷新试试
</button>
</div>
);
}
return this.props.children;
}
}

// 使用的时候
<ErrorBoundary>
<Suspense fallback={<Loading />}>
<LazyComponent />
</Suspense>
</ErrorBoundary>

坑三：生产环境能跑，本地开发就挂

这种"环境不一致"的问题最让人抓狂。通常是环境变量或者模式（mode）没对齐。

比如你在代码里判断：

if (process.env.NODE_ENV === 'production') {
// 生产环境才加载的代码
import('./analytics').then(module => module.init());
}

结果本地开发的时候 NODE_ENV 是 development，那段代码没执行，看起来没问题；但生产环境执行了，却发现 analytics 模块找不到，因为打包的时候出了问题。

或者用了某些只在生产环境生效的优化插件，本地开发的时候没开，结果代码行为不一致。

解决思路：尽量保持开发和生产环境的一致性，至少逻辑上要一致。可以用 .env 文件管理环境变量，并且在代码里做好兼容处理。

// 更安全的环境判断
const initAnalytics = async () => {
if (import.meta.env.PROD) { // Vite
try {
const { init } = await import('./analytics');
init();
} catch (e) {
console.warn('分析模块加载失败:', e);
}
}
};

坑四：循环依赖导致打包卡死或分割失效

循环依赖是模块化开发的噩梦。A 依赖 B，B 依赖 C，C 又依赖 A，这种闭环会让打包工具很困惑，有时候能正常打包，但运行时报错；有时候直接打包卡死。

怎么发现？可以用 madge 这个工具检测：

# 安装
npm install -g madge

# 检测循环依赖
madge –circular –extensions js,jsx,ts,tsx ./src

如果发现循环依赖，解决办法通常是重构代码，把公共逻辑抽离出来。比如：

// 原来：A.js 和 B.js 循环依赖
// A.js
import { b } from './B';
export const a = () => {
console.log('a');
b();
};

// B.js
import { a } from './A';
export const b = () => {
console.log('b');
// 某种情况下调用 a
if (condition) a();
};

// 解决：抽离公共逻辑到 C.js
// C.js
export const sharedLogic = () => {
console.log('shared');
};

// A.js
import { sharedLogic } from './C';
import { b } from './B';
export const a = () => {
sharedLogic();
b();
};

// B.js
import { sharedLogic } from './C';
export const b = () => {
sharedLogic();
// 不再直接依赖 A
};

实在抽离不了，就用动态 import 打破循环，把同步依赖变成异步依赖。

开发技巧：从及格到优秀

别迷信默认配置

打包工具的默认配置是照顾大多数人的，但你的项目肯定有特殊性。学会看文档调优，特别是 splitChunks 的粒度控制。

比如你发现某个公共模块被重复打包到多个 chunk 里了，可以调整 minChunks 参数：

optimization: {
splitChunks: {
cacheGroups: {
common: {
minChunks: 2, // 被两个以上 chunk 引用就提取出来
priority: 5,
reuseExistingChunk: true, // 复用已经存在的 chunk
},
},
},
},

或者你觉得分割得太碎了，想合并一些小 chunk，可以调大 minSize：

splitChunks: {
minSize: 30000, // 30KB 以下的不单独分割
maxSize: 250000, // 超过 250KB 的尝试再分割
}

魔法注释：给 chunk 起个好名字

动态 import 默认生成的文件名是一串 hash，比如 1.a3f4b2c1.js，线上报错的时候你根本不知道这是哪个文件。可以用魔法注释给 chunk 起名：

// Webpack 的魔法注释
const Dashboard = lazy(() => import(
/* webpackChunkName: "dashboard" */
/* webpackPrefetch: true */
'./pages/Dashboard'
));

const UserProfile = lazy(() => import(
/* webpackChunkName: "user-profile" */
'./pages/UserProfile'
));

这样打包出来的文件就是 dashboard.a3f4b2c1.js，看着就明白。webpackPrefetch: true 还能告诉浏览器空闲的时候预加载这个模块，用户点过去的时候能更快打开。

Vite 也支持类似的注释，用 vite-plugin-webpackchunkname 插件可以实现兼容。

Preload 和 Prefetch：别让浏览器做无用功

这两个标签都能优化加载性能，但用法不一样：

• Preload：当前页面马上要用到的资源，优先级高。比如路由懒加载时，用户鼠标悬停在菜单上的时候，可以 preload 对应的页面。
• Prefetch：当前页面可能用得到的资源，优先级低，浏览器空闲时再加载。比如用户可能在当前页待一会儿，然后会去另一个页面，就可以 prefetch 那个页面的代码。

在 Webpack 里用魔法注释：

// 预加载，优先级高
import(/* webpackPreload: true */ 'ChartComponent');

// 预获取，优先级低，空闲时加载
import(/* webpackPrefetch: true */ 'SettingsPage');

Vue 的异步组件也支持：

const SettingsPage = defineAsyncComponent({
loader: () => import('./SettingsPage.vue'),
delay: 200,
timeout: 3000,
// 配置预加载
onError(error, retry, fail, attempts) {
if (attempts <= 3) {
retry();
} else {
fail();
}
},
});

手动在 HTML 里加 link 标签也行：

<!– 预加载关键资源 –>
<link rel="preload" href="/js/critical.js" as="script">
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

<!– 预获取可能用到的资源 –>
<link rel="prefetch" href="/js/dashboard.js">
<link rel="prefetch" href="/js/settings.js">

但别滥用，preload 太多会占用带宽，反而影响首屏；prefetch 太多会浪费用户流量。精准打击，有的放矢。

Module Federation：微前端的高级玩法

如果你在做微前端架构，多个独立部署的应用需要共享组件或库，Module Federation 是个神器。它允许一个应用动态加载另一个应用的代码，就像加载本地模块一样。

配置稍微复杂点，但用熟了真香。主应用配置：

// webpack.config.js (Host)
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
// 声明远程应用
app1: 'app1@http://localhost:3001/remoteEntry.js',
app2: 'app2@http://localhost:3002/remoteEntry.js',
},
shared: {
// 共享的依赖，避免重复加载
react: { singleton: true, eager: true },
'react-dom': { singleton: true, eager: true },
},
}),
],
};

远程应用配置：

// webpack.config.js (Remote)
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app1',
filename: 'remoteEntry.js',
exposes: {
// 暴露的模块
'./Button': './src/components/Button',
'./utils': './src/utils',
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true },
},
}),
],
};

使用的时候：

// 动态加载远程组件
const RemoteButton = lazy(() => import('app1/Button'));

function App() {
return (
<div>
<h1>主应用</h1>
<Suspense fallback="加载远程组件…">
<RemoteButton />
</Suspense>
</div>
);
}

这样不同的团队可以独立开发和部署自己的应用，同时共享公共库，用户也不会重复下载 React 这些基础库。高级玩家必备技能。

最后那点碎碎念

写到这儿，我想唠叨几句。优化真的是个无底洞，你总能找到可以再压缩几 KB 的地方，总能发现某个加载指标还能再提升几十毫秒。但别忘了，我们写代码是为了解决问题，不是为了刷分。

我见过有人为了把 Lighthouse 分数从 95 刷到 100，花了整整一周时间，把代码结构改得面目全非，后续维护成本暴增。但用户真的能感受到那 5 分的差别吗？大概率不能。有时候 90 分就够了，留点时间陪陪家人，或者去学学新技术，比那几分实在多了。

工具是为人服务的，别成了配置的奴隶。Webpack 配置写得再溜，不如多关心关心用户体验。用户觉得快才是真的快，跑分软件说得再好听，用户用着卡也是白搭。

下次产品经理再催着加功能，就把打包分析报告甩给他看："老板，再加代码网页就要变成’加载中’永动机了，要不咱们先把现有的优化一下？"说不定他一看那几兆的体积，就同意给你时间做重构了呢。

总之，打包和代码分割这事儿，说难不难，说简单也不简单。关键是理解原理，根据实际场景灵活调整，别生搬硬套。希望这篇絮絮叨叨的文章能帮你少踩几个坑，让用户少等几秒钟，让老板多看几眼性能报告。毕竟，加载快 3 倍，老板当场加薪这种美事，谁不想呢？