配了八年内容站点，今天才发现构建慢的根子根本不在算法——Astro 7 把整条工具链全换成了 Rust，这件事把内容密集型项目的账彻底变了

你做文档站、博客或者知识库的时候，有没有遇到过这种情况——项目代码改动了一行，但全站构建要等三分钟？大多数人会觉得是代码逻辑有问题，或者服务器配置不够。但根子根本不在那里。

Astro 7 刚刚发布，我跑了三个月把这件事彻底想清楚了。

根子在哪？工具链，不是代码

内容型站点最大的性能杀手其实是两件事：.astro 模板编译，和 Markdown/MDX 处理。这两块以前都是 JavaScript 写的。.astro 编译器之前是 Go 实现的，Markdown 那块跑的是 remark/rehype 这一套 unified 插件链——每处理一个 Markdown 文件都要走：解析 → remark 插件处理 → rehype 插件处理 → 输出，这一长串 JavaScript 执行。

大型内容站点构建时间往往就耗在这上面，而不是你的业务代码。

Astro 7 这次把工具链全面换了：.astro 编译器用 Rust 重写（基于 oxc 解析器），Markdown 处理换成 Sätteri——一个核心团队成员 Erika 基于 pulldown-cmark 和 oxc 用 Rust 编写的处理器。框架底层从 Rollup 切换到 Vite 8 内置的 Rolldown（同样是 Rust 实现）。

结果是：Astro 官方测的三个真实项目，astro.build 从 62.7s 降到 24.2s，提升 61%；Astro Docs 从 114.5s 降到 73.5s；Cloudflare 开发者文档（8314 个页面）从 386.9s 降到 261.9s。

注意，这些是真实项目构建时间，不是 microbenchmark。

三层 Rust 同时换，账怎么算

第一层是 .astro 编译器。原来 Go 写的，现在 Rust。Go 已经比 Node 快，但 Rust 在解析这块更快，而且新编译器语法检查更严格——未闭合的标签现在直接报错，不再静默修复。升级的时候要处理一些之前被容忍的写法。

第二层是 Markdown 流水线。Sätteri 内置了 GFM Table、Math、Footnote、Heading ID、WikiLink、Frontmatter 支持，以前这些要靠 remark/rehype 插件，现在变成了内置能力。如果你的项目依赖 unified 插件链，可以继续用旧流水线，不强制迁移。

第三层是打包层。Rolldown 1.0 正式发布，官方数据是 10-30 倍快于 Rollup，同时完整兼容 Rollup 插件 API。Mercedes-Benz.io、Ramp、Beehiiv 这些早期用户的实测数据是构建时间减少 38-64%。Vite 8 默认带 Rolldown，对用户透明，你不需要改配置。

三层同时换，叠加效果显著。内容密集型站点的提升比综合站点更明显，因为 Markdown 处理那块的收益是纯增量。

依赖项还少了

一个容易被忽略的数据：依赖项数量从 Astro v6 的 247 个降到 v7 的 190 个，减少了 57 个。这是工具链 Rust 化的附带收益——Rust 二进制分发不需要带那么多 npm 包。

迁移要注意什么

更严格的编译器是第一道坎。原来被静默修复的写法现在会报错，升级前先跑一遍构建，把 .astro 文件里的语法问题清理掉。

Markdown 流水线不强制切换。如果你依赖 remark/rehype 插件，先不要动，官方给了兼容路径。只有当你的站点构建时间主要花在 Markdown 处理上时，切换到 Sätteri 才有意义。

Rolldown 的兼容性比预期好。Rollup 插件 API 基本直接可用，但依赖 esbuild 内部的插件会有问题。生产环境上线前跑一遍完整的 E2E 测试，检查 chunk 加载、懒加载和 SSR 水合路径有没有行为差异。

什么项目值得升

内容密集型站点的收益最明显——文档站、博客、SaaS 官网，这些构建时间往往被 Markdown 处理卡住。纯应用型项目（大量交互逻辑、API 调用）收益相对小，因为编译器那块本来就是增量。

Astro 7 还给 AI 编程工具加了专门的支持：astro dev –background 后台开发和 JSON 日志输出，Claude Code、Cursor、Copilot Agent 这类工具的体验会好一些。这是 AI 时代的一个信号——框架开始认真对待 Agent 的工作方式。

下一步：如果你现在跑的是 Astro 6，先跑一遍全站构建记下时间，再切到 v7 对比。内容站点的话，这个时间差通常在半分钟以上，值得做。