Astro 7.2 的增量构建，对写博客的人意味着什么：几千篇文章的站，改一篇不用全量重建

如果你也用 Astro 写博客，而且文章越攒越多，那 Astro 7.2 里藏的一个实验性功能，值得你多看两眼：增量静态构建（incremental static builds）。

我第一次看到的时候，反应是：终于来了。

以前最烦的是什么

用过静态博客框架的人都知道一个痛苦：你辛辛苦苦写了 300 篇文章，某天想改其中一篇的错别字、或者加个标签，点一下发布——然后构建脚本默默地把全站 300 篇重新生成一遍。

文章少的时候无所谓，几十秒的事。可一旦到了几百、上千篇，或者你接了 MDX、图片处理、RSS、站点地图这些，一次全量构建动辄几分钟甚至更久。CI 时长在烧钱，你改个标点的反馈循环也变慢。更烦的是，明明只动了一篇，却要等整站”重启”。

这就是内容站的隐形成本：你的构建时间，是和文章总数绑定的。

Astro 7.2 改了什么

8 月初发布的 Astro 7.2，在 experimental.incrementalBuild 后面，塞进了增量构建的能力。

逻辑很直接：每篇内容算一个 cacheKey（对内容集合来说，用 entry.digest 最自然），构建时只重建那些”真的变了”的路由，没动的页面直接复用缓存。你改了一篇，就只重建那一篇相关的页面、以及可能被牵连的列表页/首页；其余几百篇原封不动。

对大站来说，这差别是数量级的。以前改一篇 = 全站重来；现在改一篇 = 几秒钟。

而且这已经是 Astro 7 系列”把性能当头等大事”的延续：7.0 把编译器用 Rust 重写了（构建快了 15%–61%），7.1 在 CSP、分页、开发服务器上做精细控制，到了 7.2，终于把”增量构建”这颗很多人期待的棋子落下了。看得出来，Astro 团队是真的在围着”内容站”这个核心场景死磕。

对写博客的人，意味着什么

我自己的感受，三个字：省、快、稳。

• 省：CI 构建分钟数直接下来。文章越多，省得越夸张。对个人博主，可能只是少等几十秒；但对托管在按构建时长计费平台上的大站，这就是真金白银。
• 快：改稿、调版式、加个友链，反馈循环从”泡杯茶等构建”变成”刷新就好”。写作心流不被打断，这件事比想象中重要。
• 稳：全量重建越多，越容易在某个环节出幺蛾子（某篇 MDX 抽风、某张图挂了）。增量构建把爆炸半径压到最小——一篇出问题，不至于连累全站发不出去。

但先别急着全开

老实说，这个功能现在还是 experimental。我的建议是：

• 先用在小改动、非关键发布的场景试，感受一下命中缓存对不对。
• 确认你的部署目标（Netlify / Vercel / Cloudflare 这些）对增量产物支持到位，别出现”本地增量、上线全量”的尴尬。
• 真要上生产，先在 staging 站跑几轮，对比增量和全量的输出是否一致。

Astro 官方也明确说了这是实验特性，未来 API 还可能调。所以我的态度是：现在就了解、就尝鲜，但关键发布流程里先留一手全量构建兜底。

我的判断

回头看这一年的 Astro，方向越来越清楚：零 JS 默认输出、Rust 编译器、增量构建——它一直在把”认真写内容的人”的体验，打磨到别的框架不太愿意花力气的地步。

很多人选静态博客框架，图的就是”写完就发、干净、快”。Astro 现在把这三点里的”快”，从发布那一刻，一路优化到了”改一篇也快”。对一个和我一样、文章只会越写越多的人来说，这种”朝着内容创作者痛点迭代”的框架，才是值得长期托付的。

如果你还在用别的框架、被全量构建折磨，或者正打算搭新站——Astro 7.2 这个增量构建，是个很合适的理由，去认真看它一眼。