Astro 7.4 发布：--timings 给构建装上『体检镜』，并行预渲染让大站不再干等

Astro 7.4 昨天（10 月 15 日）发布了。这版没有那种一眼惊艳的大功能，但我反而觉得，它是近期最值得关注的一次更新——因为它开始认真解决静态站”长大之后”的烦恼：构建太慢，而且不知道慢在哪。

先说最实用的一条：astro build --timings。

以前构建慢，你只能靠猜。是 Vite 插件拖了后腿？Markdown 语法高亮吃 CPU？还是某个页面组件太重？7.4 加了这个 flag 之后，构建完会打印一份结构化报告：各个构建阶段各花多少时间、页面渲染合计多少、最慢的页面是哪些（还带 median 和 p95）、Vite 插件、Markdown 处理、图片转换、集成，逐项给你列出来。

Astro 官方演示里有个很典型的例子：一个带评论区的博客模板，页面生成占了整个构建时间的 81%——原因是组件里串行地 fetch 评论、再逐个 fetch 评论者的资料。把请求改成 Promise.all 并行、把数据往下传之后，页面生成时间从 2.10 秒掉到 1.13 秒。没有 --timings 之前，这种串行依赖你得自己写埋点才能发现；现在一条命令就照出来了。

第二个变化是图片服务的拆分。预渲染页面和按需/边缘页面，图片处理的约束完全不一样：构建期有完整 Node 环境，可以用 Sharp 这种本地优化器；但运行时和边缘环境往往跑不了 Sharp，更适合走图片 CDN。以前一个图片服务得两头兼顾，7.4 允许你分开配——构建期用 Sharp，运行时用 CDN，@astrojs/cloudflare 这类适配器也顺势把预渲染图片并进了统一管线。

第三个，也是我最有感的一条：实验性的并行预渲染（experimental.parallelPrerender）。以前静态页面渲染是单线程的，哪怕你的机器有八个核，也是一个页面一个页面地排队。开了这个 flag 之后，Astro 会把静态页渲染分发到 Node worker 线程上，默认用满所有 CPU 核减一个，也可以用 workers: 4 手动限制。

当然，它有几个务实的注意点：每个 worker 都会增加内存占用，构建 OOM 了先减 worker 数；模块级变量在并行渲染的页面之间不共享；getStaticPaths() 返回函数、类实例这种不可序列化值的页面不能参与并行；Cloudflare 适配器因为有自己的预渲染管线，会忽略这个 flag 并打警告。官方也明确建议：先跑 --timings 看清楚瓶颈到底在渲染还是打包还是图片，再决定要不要开并行——别一上来就无脑开。

其他小改动：自定义 entrypoint（astro/fetch、astro/hono）补上了 notFound() 处理器，以前拼 handler 时匹配不到会返回空 404，现在能正确渲染 404 页面了；字体配置新增警告，会提示你请求的字体属性和 provider 实际提供的不一致；最低 Node 版本升到 22.22.0——升级前记得先检查环境。

聊聊我的看法。Astro 过去两年最吸引人的是”上手简单、性能好”，但当博客长到几百上千个页面、构建从几秒涨到几分钟，那些卖点就会变成痛点。7.4 这版的思路很清楚：先让你看得见慢在哪（--timings），再把多核利用起来（并行预渲染），最后把图片这种最容易出幺蛾子的环节拆干净。这是典型的”工具成熟期”动作——功能堆得差不多之后，开始优化自己的构建体验本身。

对独立博客主来说，如果站点不大、构建几秒完成，这版升级动力主要是安全性和 Node 版本对齐；但如果你有几百篇文章、构建开始按分钟算，--timings 和并行预渲染值得立刻试一下。静态站的优势是快，但”构建也快”这件事，不能只靠默认配置，得靠工具把瓶颈暴露出来。Astro 7.4 做对了这一步。