Astro 的岛屿架构是我近几年接触前端新方案后第一个觉得“可以把性能问题从根源上重新定义”的思路。以前做页面优化大家拼的是压缩体积、拆包、上CDN、缓存策略说白了都是在已有产物里抠空间但岛屿架构直接改变了问题的提问方式——哪些页面内容必须加载脚本哪些可以完全不碰JavaScript。这篇文章我会从架构演进、Astro 的落地机制、具体实操到踩坑记录完整拆一遍这套方案帮你在自己的项目里判断它到底合不合适。1. 岛屿架构到底解决了什么问题——先把它脱胎于何处讲清楚1.1 从MPA到SPA的极端摆动再到“缺什么补什么”如果你是从jQuery时代写过来的前端应该对MPA多页面应用不陌生。那时候每个页面都是独立的HTML点击跳转就刷新页面服务器直接把整张页面吐回来交互逻辑靠零散的script标签撑着。这种方式最大的好处是首屏成本低——浏览器拿到什么就渲染什么最大的坏处是页面切换有白屏等待交互组件一多脚本管理就成了一团乱麻。后来SPA单页面应用把这个问题解决了但解决方式有点用力过猛。React、Vue这类框架把整个应用塞进一个div idroot里前端拿到一个几乎空白的HTML外壳再通过JavaScript把整棵组件树渲染出来。这种方式在后台管理系统、重交互应用里非常好用因为它让页面切换变成了纯前端动作不再依赖服务器往返。但代价同样明显哪怕你的页面只有一个按钮需要交互浏览器也得下载、解析、执行整套框架运行时。一个内容站首页可能只有一篇长文和一个评论区却要为一个评论框付出几百KB的成本。后来SSR服务端渲染和静态站点生成出现了Next.js、Nuxt这类框架在服务端把React/Vue组件渲染成HTML字符串再在浏览器端做水合hydration让页面既有SEO又有交互。但这里有个隐藏问题这种方案是“全量水合”。服务端确实把整张HTML吐出来了可浏览器端脚本一启动还是会挨个激活页面上所有组件哪怕有些组件根本不需要任何交互逻辑。一个详情页99%的内容都是静态文本浏览器依然要为整个页面绑定事件、初始化状态、构建虚拟DOM树。性能能比纯客户端渲染好但离“零浪费”还有不小距离。1.2 岛屿架构大片静态海洋中的交互小岛岛屿架构Islands Architecture的核心比喻特别直观把整张页面想象成一片海洋海洋里的绝大多数区域都是静态的、不需要JavaScript参与的HTML只有少数交互组件像是分布在海面上的岛屿浏览器只需要针对这些“岛屿”加载脚本、执行水合其他部分全部保持静态。这个概念最初由Etsy的前端架构师Katie Sylor-Miller提出后来在Astro、Eleventy等框架中被大规模落地。Astro把它作为默认设计原则每个.astro组件编译后默认输出纯HTML和CSSJavaScript字节数为零。只有你在模板里显式给组件加上client:*指令Astro才会把该组件及其依赖打包成独立的JavaScript chunk在指定时机加载并水合。这意味着两点。第一打包产物是页面维度的不是应用维度的。每个交互组件对应一个或几个独立脚本页面引入了三个交互组件浏览器就最多加载三个脚本而不是一个包含整个应用逻辑的大包。第二静态内容完全游离在框架运行时之外。React/Vue/Svelte的runtime只在被激活的岛屿内部起作用不会“感染”周围的大片静态HTML。1.3 岛屿架构与SSR全量水合的根本差异把岛屿架构和传统SSR放在一起对比差异非常清晰。传统SSR的工作流是服务端渲染出HTML → 浏览器显示页面 → 下载整个应用脚本 →在页面根节点上执行全量水合。水合的过程等于重新跑一遍React/Vue在客户端的所有逻辑把虚拟DOM和真实DOM做匹配绑定事件代理初始化状态。页面里的静态部分是顺带被“水合”的它们本身没这个需求但用户必须为它们买单。岛屿架构则是服务端/构建期渲染出HTML → 浏览器显示页面 →只下载并水合被标记的交互岛屿→ 静态区域保持纯HTML。成本从“整个应用”变成“每个岛屿各自承担”。更妙的是这种水合的粒度是组件级的岛屿之间互相独立没有全局事件总线或共享运行时依赖你可以混用React、Vue、Svelte写的不同岛屿组件只要它们各自编译出的脚本互不依赖就行。我用一个数字来直观说明我之前把一个React的SSR信息流页面迁移到Astro页面上只有一个搜索框和导航栏是交互组件其余全是文章列表内容。迁移前HTML约80KB、JavaScript约245KB迁移后HTML变成了120KB左右更多静态内容被直接输出JavaScript降到了12KB只剩一个搜索框的逻辑。首屏渲染时间在低端Android设备上大约快了一倍因为浏览器省去了下载、解析、执行200多KB脚本的大量时间。2. Astro如何把岛屿架构落成代码——核心机制逐个拆2.1 默认零JavaScript的编译模型Astro最反直觉的地方在于虽然你可以在项目里写React、Vue、Svelte组件但Astro本身是一个编译时框架不是运行时框架。它没有像Next.js那样在浏览器端跑一个“Astro运行时”来调度一切。Astro构建器会在编译阶段读取所有.astro文件把它们转换成静态HTML字符串再把页面引用的框架组件编译成独立脚本模块。这个设计带来了一个很多人容易忽略的事实Astro项目最终产出的静态站点几乎没有“框架壳”。你部署到服务器上的文件是纯HTML、CSS、JS不包含任何运行时引导逻辑。这一点和Hugo、Eleventy这类静态站点生成器有点像但区别在于Astro允许你在静态页面里嵌入真正的交互组件而不是回到jQuery手写事件的老路。在Astro中每个.astro文件里的组件代码分为两部分---里面的frontmatter部分编译时执行Node.js环境以及模板部分输出HTML。frontmatter里可以写任意的JavaScript/TypeScript逻辑比如拉取数据、计算日期、生成静态路径这些代码只会在编译期跑一次产物里不会保留任何影子。模板里的变量插值也全部在编译期完成最终输出是纯字符串拼接的结果。2.2 client指令告诉Astro何时激活哪座岛屿岛屿本身是“死”的你得明确告诉Astro哪些组件需要水合、什么时候水合。这就是client:*指令的用途。指令写在组件标签上Astro构建器看到指令后才会为该组件生成独立的JavaScript chunk并在满足条件时执行水合逻辑。下面是我整理过的常用指令对照表指令触发时机使用场景client:load页面加载后立即水合首屏内必须立刻可用的交互组件比如导航栏、首页搜索框client:idle浏览器空闲后requestIdleCallback水合非关键交互组件如折叠面板、分享按钮client:visible元素进入视口才水合页面底部或懒加载区块内的表单、轮播图client:media(max-width: 768px)只在指定媒体查询条件满足时水合响应式组件比如移动端才需要的抽屉菜单client:onlyreact完全只在浏览器端渲染不参与SSR依赖浏览器API的组件如本地存储读写、Canvas绘图这里有个常见误解client:visible不是让你把组件放在页面底部然后“什么都不管”。Astro在实现上使用IntersectionObserver监听元素进入视口但如果你把组件放在初始视口内它很快就会触发水合。真正想做懒加载需要在视觉上让组件离开首屏或者配合CSS让它可以滚动进入。实测下来client:idle和client:visible的触发时间差异不小如果你的组件是可交互的广告位、评论区占位client:visible更稳如果是折叠面板这种大概率晚点才被点到的client:idle能有效避开首屏加载高峰。还有一点需要注意client:onlyreact需要显式指定框架名因为Astro不知道你组件文件用的是哪个框架编译出来的。如果不指定构建会报错。这个指令的典型场景是组件里有window、localStorage等浏览器API但你在SSR时又没法保护环境与其在组件内部挂typeof window undefined判断不如直接声明“我只需要在浏览器端渲染”。2.3 多框架共存一座岛上插不同的旗子Astro的另一个大胆设计是允许你在同一页面混用React、Vue、Svelte、Solid、Preact组件。这在传统SPA里几乎不可想象因为每个框架都有自己的运行时和调度机制混在一起要么体积爆炸要么状态不同步。但Astro的岛屿架构天然适合混用岛屿之间没有共享运行时每个框架的脚本都隔离在自己那片小岛上互不干扰。实际操作中你需要分别在astro.config.mjs里注册对应的框架集成// astro.config.mjs import { defineConfig } from astro/config; import react from astrojs/react; import vue from astrojs/vue; import svelte from astrojs/svelte; export default defineConfig({ integrations: [react(), vue(), svelte()], });然后在.astro页面里这样混用--- import ReactCounter from ../components/ReactCounter.tsx; import VueCounter from ../components/VueCounter.vue; import SvelteCounter from ../components/SvelteCounter.svelte; --- ReactCounter client:load / VueCounter client:visible / SvelteCounter client:idle /这三个组件各自编译成独立的脚本水合时机也完全独立。我喜欢混用的一个真实场景是主技术栈是React但某个老项目留下了几个Vue的图表组件不想重写。迁到Astro之后直接把Vue组件像普通模块一样引入加client:visible之后它们工作得老老实实。代价是每个框架各自的运行时都单独打包但既然它们只在自己岛屿上运行这部分成本是显性的、可控的不会像SPA那样你引入一个框架就要背负全站。3. 用Astro搭建一个带交互岛屿的页面——从初始化到验证3.1 项目初始化与目录结构设计先说明一下环境。我写这篇文章时Astro最新稳定版是5.xNode.js建议用20版本以上。初始化命令很简单# 创建项目交互式CLI npm create astrolatest my-island-site # 进入目录 cd my-island-site # 安装依赖 npm install # 本地开发 npm run devCLI会让你选择模板新手选Basic就够。创建出来的目录结构大致是my-island-site/ ├── src/ │ ├── components/ # 岛屿组件放这里.astro/.tsx/.vue/.svelte │ ├── layouts/ # 页面布局骨架 │ ├── pages/ # 路由页面文件路径即URL路径 │ └── content.config.ts # 内容集合配置Astro 5.x ├── public/ # 静态资源目录直接复制到产物 ├── astro.config.mjs └── package.jsonAstro的目录规范很有意思src/pages下每个.astro或.md文件都会变成一个路由文件路径就是URL路径。这在内容站点里效率极高因为你想新增一个“关于我们”页面只要新建src/pages/about.astro刷新浏览器就能直接访问/about不用手动注册路由。3.2 写一个React岛屿组件并激活它我现在创建两个文件来演示最核心的岛屿激活流程。第一个是React组件用最简单的方式写一个计数器// src/components/Counter.tsx import { useState } from react; export default function Counter() { const [count, setCount] useState(0); return ( div style{{ padding: 1rem, border: 1px solid #ddd }} p当前计数{count}/p button onClick{() setCount(c c 1)}加一/button /div ); }注意这里没有export const config之类的Astro专用标记就是一个普通的React组件。接下来在页面里引入它并决定它什么时候水合--- // src/pages/index.astro import Layout from ../layouts/Layout.astro; import Counter from ../components/Counter.tsx; --- Layout title岛屿架构演示 h1岛屿架构实战/h1 p这一段是纯静态HTML浏览器不需要加载任何JavaScript。/p Counter client:load / p这一段同样是静态内容。/p /Layout在开发模式下npm run dev会启动Astro的开发服务器页面加载后你会看到Counter组件正常交互。但我建议你用npm run build npm run preview跑一次生产构建再在浏览器里看Network面板。你会发现请求资源里只有这个页面对应的HTML文件以及Counter组件编译出的一个独立JS文件。页面上其余内容完全没有对应的脚本资源。3.3 用Content Collections管理静态内容把“海洋”做大岛屿架构的另一个隐藏优势是它和内容型站点天然契合。Astro 5.x把内容管理做成了内置功能叫Content Collections内容集合。简单说你可以定义一类内容的schema和存放目录然后Astro会在编译期读取这些内容并生成静态页面。我自己的博客就是靠这个功能从零搭的不用接任何CMS。先配置一个内容集合以博客文章为例// src/content.config.ts import { defineCollection, z } from astro:content; const postsCollection defineCollection({ type: content, schema: z.object({ title: z.string(), date: z.date(), tags: z.array(z.string()).default([]), description: z.string(), }), }); export const collections { posts: postsCollection, };然后在src/content/posts/下创建Markdown文件例如hello-islands.mdfrontmatter里写元信息正文写内容。在页面里通过getCollection拿到所有文章数据--- import { getCollection } from astro:content; const posts await getCollection(posts); --- ul {posts.map(post ( li a href{/posts/${post.id}}{post.data.title}/a time datetime{post.data.date.toISOString()} {post.data.date.toLocaleDateString()} /time /li ))} /ulContent Collections和岛屿架构的最佳结合点是列表页是静态的但列表上的交互行为是岛屿。比如你给每篇文章加一个“收藏”按钮这个按钮就是一个client:visible的Svelte小岛列表本身永远是纯HTML浏览器不用运行任何框架代码。内容一多这个优势会被无限放大。3.4 构建产物检查用数据验证岛屿是否按需加载文章写到这里光说不练是空的。我建议所有用Astro的人在拿到一个页面之后都跑一次npm run build构建完成后看dist/目录。你会发现每个页面都生成一个对应的index.html而最终的JavaScript文件会按岛屿模块拆分。用grep或者编辑器搜索HTML里的script标签能看到只有被标记了client:*的组件才带有typemodule的脚本引用。我实际做过的优化实验里一个包含30篇博客列表的页面全静态内容时HTML大约是35KB页面里放了一个React的“目录高亮”组件client:visible后新增了一个4.8KB的脚本。整个页面加起来的传输成本比传统React应用渲染同样内容要低一个数量级。如果还嫌不够再配合astro compress这类插件对HTML和静态资源做gzip/brotli压缩静态站点通常能压到初始HTML 10KB以内这几乎是传统SPA无法想象的首屏成本。提示验证岛屿是否被正确激活最直接的方法是看Waterfall里的脚本加载时机。页面加载后client:load的脚本会立即开始请求client:visible的脚本只在对应DOM元素滚入视口前后才发起请求。如果某个组件在首屏就加载了你不希望它加载的脚本检查一下标签上的指令是不是client:load。4. 从实践里长出来的避坑经验——比文档更值钱的细节4.1 水合时机选择的三个判断维度文档只会告诉你client:load是页面加载后水合client:idle是浏览器空闲后水合但实际业务选择时我建议按三个维度判断第一这个交互是否影响首屏关键路径。导航栏、购物车入口、首屏搜索框、视频播放器这些用户进入页面立刻可能操作的组件直接上client:load。它们虽然会让首屏脚本多几十KB但换来的响应速度是实打实的。第二这个交互对用户的可见概率。页面底部“返回顶部”按钮、折叠面板、分页加载器这些组件大概率在用户滚动之后才出现用client:visible是最优选择。第三这个交互是否可以延后到空闲时段。像评论区的“表情选择器”、文章页的“字号调整面板”用户不一定用用了也得等那就client:idle。我踩过最大的坑是把一个图片懒加载组件标记成client:load结果整个页面的LCP最大内容绘制被拖慢了。因为Astro虽然只加载这个组件本身的脚本但脚本执行时会调用IntersectionObserver监听一组图片这个注册过程本身让浏览器在解析HTML时就不得不处理一段JavaScript。后来改成client:visibleLCP立刻恢复了纯静态页面的水准。记住岛屿指令不只是打包开关它直接影响浏览器的加载和执行顺序地图有多大岛屿就应该在哪个时间点醒来。4.2 岛屿通信别指望一座岛知道另一座岛的内部状态这是新手最容易犯的错误。既然Astro把组件隔离成独立岛屿那React组件和Vue组件之间、甚至两个React组件之间都无法像SPA那样直接通过全局Context或Redux共享状态。岛屿架构的设计哲学就是状态应该扁平化。实践中有几种替代方案。如果两个岛屿之间需要共享少量数据用>
Astro岛屿架构：从根源上重定义前端性能优化
Astro 的岛屿架构是我近几年接触前端新方案后第一个觉得“可以把性能问题从根源上重新定义”的思路。以前做页面优化大家拼的是压缩体积、拆包、上CDN、缓存策略说白了都是在已有产物里抠空间但岛屿架构直接改变了问题的提问方式——哪些页面内容必须加载脚本哪些可以完全不碰JavaScript。这篇文章我会从架构演进、Astro 的落地机制、具体实操到踩坑记录完整拆一遍这套方案帮你在自己的项目里判断它到底合不合适。1. 岛屿架构到底解决了什么问题——先把它脱胎于何处讲清楚1.1 从MPA到SPA的极端摆动再到“缺什么补什么”如果你是从jQuery时代写过来的前端应该对MPA多页面应用不陌生。那时候每个页面都是独立的HTML点击跳转就刷新页面服务器直接把整张页面吐回来交互逻辑靠零散的script标签撑着。这种方式最大的好处是首屏成本低——浏览器拿到什么就渲染什么最大的坏处是页面切换有白屏等待交互组件一多脚本管理就成了一团乱麻。后来SPA单页面应用把这个问题解决了但解决方式有点用力过猛。React、Vue这类框架把整个应用塞进一个div idroot里前端拿到一个几乎空白的HTML外壳再通过JavaScript把整棵组件树渲染出来。这种方式在后台管理系统、重交互应用里非常好用因为它让页面切换变成了纯前端动作不再依赖服务器往返。但代价同样明显哪怕你的页面只有一个按钮需要交互浏览器也得下载、解析、执行整套框架运行时。一个内容站首页可能只有一篇长文和一个评论区却要为一个评论框付出几百KB的成本。后来SSR服务端渲染和静态站点生成出现了Next.js、Nuxt这类框架在服务端把React/Vue组件渲染成HTML字符串再在浏览器端做水合hydration让页面既有SEO又有交互。但这里有个隐藏问题这种方案是“全量水合”。服务端确实把整张HTML吐出来了可浏览器端脚本一启动还是会挨个激活页面上所有组件哪怕有些组件根本不需要任何交互逻辑。一个详情页99%的内容都是静态文本浏览器依然要为整个页面绑定事件、初始化状态、构建虚拟DOM树。性能能比纯客户端渲染好但离“零浪费”还有不小距离。1.2 岛屿架构大片静态海洋中的交互小岛岛屿架构Islands Architecture的核心比喻特别直观把整张页面想象成一片海洋海洋里的绝大多数区域都是静态的、不需要JavaScript参与的HTML只有少数交互组件像是分布在海面上的岛屿浏览器只需要针对这些“岛屿”加载脚本、执行水合其他部分全部保持静态。这个概念最初由Etsy的前端架构师Katie Sylor-Miller提出后来在Astro、Eleventy等框架中被大规模落地。Astro把它作为默认设计原则每个.astro组件编译后默认输出纯HTML和CSSJavaScript字节数为零。只有你在模板里显式给组件加上client:*指令Astro才会把该组件及其依赖打包成独立的JavaScript chunk在指定时机加载并水合。这意味着两点。第一打包产物是页面维度的不是应用维度的。每个交互组件对应一个或几个独立脚本页面引入了三个交互组件浏览器就最多加载三个脚本而不是一个包含整个应用逻辑的大包。第二静态内容完全游离在框架运行时之外。React/Vue/Svelte的runtime只在被激活的岛屿内部起作用不会“感染”周围的大片静态HTML。1.3 岛屿架构与SSR全量水合的根本差异把岛屿架构和传统SSR放在一起对比差异非常清晰。传统SSR的工作流是服务端渲染出HTML → 浏览器显示页面 → 下载整个应用脚本 →在页面根节点上执行全量水合。水合的过程等于重新跑一遍React/Vue在客户端的所有逻辑把虚拟DOM和真实DOM做匹配绑定事件代理初始化状态。页面里的静态部分是顺带被“水合”的它们本身没这个需求但用户必须为它们买单。岛屿架构则是服务端/构建期渲染出HTML → 浏览器显示页面 →只下载并水合被标记的交互岛屿→ 静态区域保持纯HTML。成本从“整个应用”变成“每个岛屿各自承担”。更妙的是这种水合的粒度是组件级的岛屿之间互相独立没有全局事件总线或共享运行时依赖你可以混用React、Vue、Svelte写的不同岛屿组件只要它们各自编译出的脚本互不依赖就行。我用一个数字来直观说明我之前把一个React的SSR信息流页面迁移到Astro页面上只有一个搜索框和导航栏是交互组件其余全是文章列表内容。迁移前HTML约80KB、JavaScript约245KB迁移后HTML变成了120KB左右更多静态内容被直接输出JavaScript降到了12KB只剩一个搜索框的逻辑。首屏渲染时间在低端Android设备上大约快了一倍因为浏览器省去了下载、解析、执行200多KB脚本的大量时间。2. Astro如何把岛屿架构落成代码——核心机制逐个拆2.1 默认零JavaScript的编译模型Astro最反直觉的地方在于虽然你可以在项目里写React、Vue、Svelte组件但Astro本身是一个编译时框架不是运行时框架。它没有像Next.js那样在浏览器端跑一个“Astro运行时”来调度一切。Astro构建器会在编译阶段读取所有.astro文件把它们转换成静态HTML字符串再把页面引用的框架组件编译成独立脚本模块。这个设计带来了一个很多人容易忽略的事实Astro项目最终产出的静态站点几乎没有“框架壳”。你部署到服务器上的文件是纯HTML、CSS、JS不包含任何运行时引导逻辑。这一点和Hugo、Eleventy这类静态站点生成器有点像但区别在于Astro允许你在静态页面里嵌入真正的交互组件而不是回到jQuery手写事件的老路。在Astro中每个.astro文件里的组件代码分为两部分---里面的frontmatter部分编译时执行Node.js环境以及模板部分输出HTML。frontmatter里可以写任意的JavaScript/TypeScript逻辑比如拉取数据、计算日期、生成静态路径这些代码只会在编译期跑一次产物里不会保留任何影子。模板里的变量插值也全部在编译期完成最终输出是纯字符串拼接的结果。2.2 client指令告诉Astro何时激活哪座岛屿岛屿本身是“死”的你得明确告诉Astro哪些组件需要水合、什么时候水合。这就是client:*指令的用途。指令写在组件标签上Astro构建器看到指令后才会为该组件生成独立的JavaScript chunk并在满足条件时执行水合逻辑。下面是我整理过的常用指令对照表指令触发时机使用场景client:load页面加载后立即水合首屏内必须立刻可用的交互组件比如导航栏、首页搜索框client:idle浏览器空闲后requestIdleCallback水合非关键交互组件如折叠面板、分享按钮client:visible元素进入视口才水合页面底部或懒加载区块内的表单、轮播图client:media(max-width: 768px)只在指定媒体查询条件满足时水合响应式组件比如移动端才需要的抽屉菜单client:onlyreact完全只在浏览器端渲染不参与SSR依赖浏览器API的组件如本地存储读写、Canvas绘图这里有个常见误解client:visible不是让你把组件放在页面底部然后“什么都不管”。Astro在实现上使用IntersectionObserver监听元素进入视口但如果你把组件放在初始视口内它很快就会触发水合。真正想做懒加载需要在视觉上让组件离开首屏或者配合CSS让它可以滚动进入。实测下来client:idle和client:visible的触发时间差异不小如果你的组件是可交互的广告位、评论区占位client:visible更稳如果是折叠面板这种大概率晚点才被点到的client:idle能有效避开首屏加载高峰。还有一点需要注意client:onlyreact需要显式指定框架名因为Astro不知道你组件文件用的是哪个框架编译出来的。如果不指定构建会报错。这个指令的典型场景是组件里有window、localStorage等浏览器API但你在SSR时又没法保护环境与其在组件内部挂typeof window undefined判断不如直接声明“我只需要在浏览器端渲染”。2.3 多框架共存一座岛上插不同的旗子Astro的另一个大胆设计是允许你在同一页面混用React、Vue、Svelte、Solid、Preact组件。这在传统SPA里几乎不可想象因为每个框架都有自己的运行时和调度机制混在一起要么体积爆炸要么状态不同步。但Astro的岛屿架构天然适合混用岛屿之间没有共享运行时每个框架的脚本都隔离在自己那片小岛上互不干扰。实际操作中你需要分别在astro.config.mjs里注册对应的框架集成// astro.config.mjs import { defineConfig } from astro/config; import react from astrojs/react; import vue from astrojs/vue; import svelte from astrojs/svelte; export default defineConfig({ integrations: [react(), vue(), svelte()], });然后在.astro页面里这样混用--- import ReactCounter from ../components/ReactCounter.tsx; import VueCounter from ../components/VueCounter.vue; import SvelteCounter from ../components/SvelteCounter.svelte; --- ReactCounter client:load / VueCounter client:visible / SvelteCounter client:idle /这三个组件各自编译成独立的脚本水合时机也完全独立。我喜欢混用的一个真实场景是主技术栈是React但某个老项目留下了几个Vue的图表组件不想重写。迁到Astro之后直接把Vue组件像普通模块一样引入加client:visible之后它们工作得老老实实。代价是每个框架各自的运行时都单独打包但既然它们只在自己岛屿上运行这部分成本是显性的、可控的不会像SPA那样你引入一个框架就要背负全站。3. 用Astro搭建一个带交互岛屿的页面——从初始化到验证3.1 项目初始化与目录结构设计先说明一下环境。我写这篇文章时Astro最新稳定版是5.xNode.js建议用20版本以上。初始化命令很简单# 创建项目交互式CLI npm create astrolatest my-island-site # 进入目录 cd my-island-site # 安装依赖 npm install # 本地开发 npm run devCLI会让你选择模板新手选Basic就够。创建出来的目录结构大致是my-island-site/ ├── src/ │ ├── components/ # 岛屿组件放这里.astro/.tsx/.vue/.svelte │ ├── layouts/ # 页面布局骨架 │ ├── pages/ # 路由页面文件路径即URL路径 │ └── content.config.ts # 内容集合配置Astro 5.x ├── public/ # 静态资源目录直接复制到产物 ├── astro.config.mjs └── package.jsonAstro的目录规范很有意思src/pages下每个.astro或.md文件都会变成一个路由文件路径就是URL路径。这在内容站点里效率极高因为你想新增一个“关于我们”页面只要新建src/pages/about.astro刷新浏览器就能直接访问/about不用手动注册路由。3.2 写一个React岛屿组件并激活它我现在创建两个文件来演示最核心的岛屿激活流程。第一个是React组件用最简单的方式写一个计数器// src/components/Counter.tsx import { useState } from react; export default function Counter() { const [count, setCount] useState(0); return ( div style{{ padding: 1rem, border: 1px solid #ddd }} p当前计数{count}/p button onClick{() setCount(c c 1)}加一/button /div ); }注意这里没有export const config之类的Astro专用标记就是一个普通的React组件。接下来在页面里引入它并决定它什么时候水合--- // src/pages/index.astro import Layout from ../layouts/Layout.astro; import Counter from ../components/Counter.tsx; --- Layout title岛屿架构演示 h1岛屿架构实战/h1 p这一段是纯静态HTML浏览器不需要加载任何JavaScript。/p Counter client:load / p这一段同样是静态内容。/p /Layout在开发模式下npm run dev会启动Astro的开发服务器页面加载后你会看到Counter组件正常交互。但我建议你用npm run build npm run preview跑一次生产构建再在浏览器里看Network面板。你会发现请求资源里只有这个页面对应的HTML文件以及Counter组件编译出的一个独立JS文件。页面上其余内容完全没有对应的脚本资源。3.3 用Content Collections管理静态内容把“海洋”做大岛屿架构的另一个隐藏优势是它和内容型站点天然契合。Astro 5.x把内容管理做成了内置功能叫Content Collections内容集合。简单说你可以定义一类内容的schema和存放目录然后Astro会在编译期读取这些内容并生成静态页面。我自己的博客就是靠这个功能从零搭的不用接任何CMS。先配置一个内容集合以博客文章为例// src/content.config.ts import { defineCollection, z } from astro:content; const postsCollection defineCollection({ type: content, schema: z.object({ title: z.string(), date: z.date(), tags: z.array(z.string()).default([]), description: z.string(), }), }); export const collections { posts: postsCollection, };然后在src/content/posts/下创建Markdown文件例如hello-islands.mdfrontmatter里写元信息正文写内容。在页面里通过getCollection拿到所有文章数据--- import { getCollection } from astro:content; const posts await getCollection(posts); --- ul {posts.map(post ( li a href{/posts/${post.id}}{post.data.title}/a time datetime{post.data.date.toISOString()} {post.data.date.toLocaleDateString()} /time /li ))} /ulContent Collections和岛屿架构的最佳结合点是列表页是静态的但列表上的交互行为是岛屿。比如你给每篇文章加一个“收藏”按钮这个按钮就是一个client:visible的Svelte小岛列表本身永远是纯HTML浏览器不用运行任何框架代码。内容一多这个优势会被无限放大。3.4 构建产物检查用数据验证岛屿是否按需加载文章写到这里光说不练是空的。我建议所有用Astro的人在拿到一个页面之后都跑一次npm run build构建完成后看dist/目录。你会发现每个页面都生成一个对应的index.html而最终的JavaScript文件会按岛屿模块拆分。用grep或者编辑器搜索HTML里的script标签能看到只有被标记了client:*的组件才带有typemodule的脚本引用。我实际做过的优化实验里一个包含30篇博客列表的页面全静态内容时HTML大约是35KB页面里放了一个React的“目录高亮”组件client:visible后新增了一个4.8KB的脚本。整个页面加起来的传输成本比传统React应用渲染同样内容要低一个数量级。如果还嫌不够再配合astro compress这类插件对HTML和静态资源做gzip/brotli压缩静态站点通常能压到初始HTML 10KB以内这几乎是传统SPA无法想象的首屏成本。提示验证岛屿是否被正确激活最直接的方法是看Waterfall里的脚本加载时机。页面加载后client:load的脚本会立即开始请求client:visible的脚本只在对应DOM元素滚入视口前后才发起请求。如果某个组件在首屏就加载了你不希望它加载的脚本检查一下标签上的指令是不是client:load。4. 从实践里长出来的避坑经验——比文档更值钱的细节4.1 水合时机选择的三个判断维度文档只会告诉你client:load是页面加载后水合client:idle是浏览器空闲后水合但实际业务选择时我建议按三个维度判断第一这个交互是否影响首屏关键路径。导航栏、购物车入口、首屏搜索框、视频播放器这些用户进入页面立刻可能操作的组件直接上client:load。它们虽然会让首屏脚本多几十KB但换来的响应速度是实打实的。第二这个交互对用户的可见概率。页面底部“返回顶部”按钮、折叠面板、分页加载器这些组件大概率在用户滚动之后才出现用client:visible是最优选择。第三这个交互是否可以延后到空闲时段。像评论区的“表情选择器”、文章页的“字号调整面板”用户不一定用用了也得等那就client:idle。我踩过最大的坑是把一个图片懒加载组件标记成client:load结果整个页面的LCP最大内容绘制被拖慢了。因为Astro虽然只加载这个组件本身的脚本但脚本执行时会调用IntersectionObserver监听一组图片这个注册过程本身让浏览器在解析HTML时就不得不处理一段JavaScript。后来改成client:visibleLCP立刻恢复了纯静态页面的水准。记住岛屿指令不只是打包开关它直接影响浏览器的加载和执行顺序地图有多大岛屿就应该在哪个时间点醒来。4.2 岛屿通信别指望一座岛知道另一座岛的内部状态这是新手最容易犯的错误。既然Astro把组件隔离成独立岛屿那React组件和Vue组件之间、甚至两个React组件之间都无法像SPA那样直接通过全局Context或Redux共享状态。岛屿架构的设计哲学就是状态应该扁平化。实践中有几种替代方案。如果两个岛屿之间需要共享少量数据用>
