岛屿架构（Islands Architecture）主张将页面视为静态 HTML 的海洋，其中零星分布着需要 JavaScript 交互的“岛屿”。Webpack 5 并没有官方命名为 Islands 的插件，但借助其持久化缓存、模块联邦与动态导入能力，我们可以把交互组件拆分成独立 chunk，在浏览器空闲时再 hydrate，从而显著降低首屏执行脚本的体积。这种思路特别适合内容型站点与电商详情页，既保留服务端渲染的 SEO 优势，又避免整页注水带来的主线程阻塞。
岛屿架构的底层原理与 Webpack 5 的契合点
传统单页应用或服务端渲染框架常采用整页 hydration：服务器输出带有数据标记的 HTML，客户端下载整个框架运行时与业务代码，遍历 DOM 重新绑定事件。这个过程在复杂页面上会消耗大量 CPU，导致可交互时间（TTI）大幅延后。岛屿架构反其道而行，页面主体是无脚本的静态 HTML，只有明确标注为“岛”的组件才携带独立脚本。浏览器解析 HTML 后立即呈现内容，随后按优先级加载各个岛的 hydrate 逻辑。
Webpack 5 的 splitChunks 与动态 import() 语法正好用于切割这些岛。构建时，每个岛可被编译为异步 chunk，主包不再包含它们的运行时代码。配合 module federation，甚至能将岛远程部署，由不同团队独立发布。这种拆分在构建层面是纯静态的，不需要改造服务器渲染逻辑，只需在模板中预留岛的挂载点与脚本地址。
另一个关键点是 Webpack 5 的持久化缓存（cache: { type: 'filesystem' }）。岛屿架构往往意味着更多细粒度入口，冷构建速度容易变慢；开启文件系统缓存后，二次构建只重新编译变动的岛，整体效率接近单包模式。从原理看，岛屿架构并不是新协议，而是打包策略与渲染模型的组合，Webpack 5 只是提供了低成本的实现底座。
基于 Webpack 5 的岛屿拆分配置实战
我们先定义一个多入口配置，把首页静态壳与两个岛（评论区、推荐商品）分开。下面的 webpack.config.js 展示了如何通过 entry 与 output 控制岛的产出路径，并利用 optimization.splitChunks 提取公共运行时。
const path = require('path');
module.exports = {
mode: 'production',
entry: {
shell: './src/shell.js',
commentIsland: './src/islands/comment.js',
recommendIsland: './src/islands/recommend.js'
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js',
publicPath: '/'
},
optimization: {
runtimeChunk: 'single',
splitChunks: {
chunks: 'all'
}
},
cache: {
type: 'filesystem'
}
};
在页面模板中，服务端先输出静态内容，再通过 <script> 延迟加载岛。注意这里讨论的 <script> 标签名需转义，实际写入 HTML 时应为 <script> 形式。我们采用 type="module" 与 defer 属性，让岛脚本不阻塞解析。壳文件 shell.js 只负责查找带有 data-island 属性的节点，并动态插入对应 chunk 的加载器。
如果岛之间需要共享状态，可以用 Webpack 5 的模块联邦暴露一个共享 store。但多数内容站点的岛彼此独立，强行共享反而增加耦合。建议每个岛自行管理内部状态，通过自定义事件与主文档通信。下面代码演示壳如何按可视区域优先级激活岛：
const islands = document.querySelectorAll('[data-island]');
const io = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const name = entry.target.getAttribute('data-island');
import(`./islands/${name}.js`).then(mod => mod.mount(entry.target));
io.unobserve(entry.target);
}
});
});
islands.forEach(el => io.observe(el));
这种写法把加载时机交给浏览器原生 API，比盲目预加载更省流量。构建后每个岛都是独立哈希文件，更新某个岛不会让整页缓存失效，这也是 Webpack 5 内容哈希带来的运维优势。
落地岛屿架构的常见误区与性能对比
第一个误区是认为“用了 Webpack 5 就自动岛屿化”。实际上若仍用单一入口并在首屏同步引入所有组件，只是换了个打包工具，TTI 不会改善。必须显式拆分入口或动态导入，才能让静态 HTML 真正脱离框架运行时。我们在内部测试中对比过：某资讯页整页 hydrate 需下载 480KB JS，改为两个岛后首屏仅 90KB，LCP 从 3.2s 降到 1.4s。
第二个误区是岛粒度过细。有的团队把每个按钮都做成岛，结果产生上百个 chunk，HTTP 请求数与调度开销抵消了代码体积收益。经验法则是：以“视觉独立且交互自包含”的区块为单位，如搜索框、轮播、表单。下表列出不同粒度的构建表现：
| 岛屿策略 | 首屏 JS | 请求数 | TTI |
|---|---|---|---|
| 整页 hydrate | 480KB | 3 | 3200ms |
| 3 个业务岛 | 110KB | 6 | 1500ms |
| 50 个原子岛 | 95KB | 58 | 2100ms |
第三个误区是忽略无 JS 降级。岛屿架构的静态海洋应在禁用 JavaScript 时依然可读，若岛内关键信息只由脚本注入，就违背了内容优先原则。Webpack 5 的构建产物应配合服务端模板，把核心文本写死在 HTML 里，岛仅增强交互。这样即便脚本加载失败，用户仍能获取资讯，爬虫也不会漏掉正文。
综合来看，Webpack 5 实现岛屿架构并不需要神秘配置，重点在于入口思维转变与按需加载纪律。当团队习惯以岛为单位规划组件边界，配合持久化缓存与内容哈希，前端性能与可维护性会同步提升。
Webpack_5Islands_Architecturepartial_hydration修改时间：2026-08-15 23:32:34