Astro Fuwari 博客 Vercel 构建 OOM 优化实战

问题背景#

我的博客使用 Astro 构建，部署在 Vercel 上。随着文章数量增长到 500+ 篇，遇到了构建失败的问题：

1
ELIFECYCLE Command failed with exit code 137.
2
Error: Command "pnpm run build" exited with 137

51be99fdd7a7e930407980363f7f7037

Exit code 137 意味着进程被 SIGKILL 终止，通常是因为内存不足 (OOM)。Vercel 免费版提供 8GB RAM，理论上应该足够，但实际构建时内存峰值过高。

问题分析#

通过分析构建日志和代码，我发现了几个内存瓶颈：

1. getStaticPaths 传递完整 entry 对象#

这是最关键的问题。原来的代码：

1
export async function getStaticPaths() {
2
    const posts = await getSortedPosts();
3
    return posts.map((entry) => ({
4
        params: { slug: entry.id },
5
        props: { entry },  // 传递完整 entry 对象！
6
    }));
7
}

这意味着 500 篇文章的完整内容都被存储在路由 props 中，同时占用内存。

2. 默认无限制并发构建#

Astro 默认会尽可能多地并行构建页面，在内存受限环境下会导致峰值过高。

3. HTML 压缩消耗额外内存#

虽然 HTML 压缩可以减少文件大小，但在构建时需要额外内存。而 CDN（如 Cloudflare、Vercel）会自动使用 Brotli 压缩传输，本地压缩意义不大。

优化方案#

1. 核心优化：getStaticPaths 只传递必要数据#

1
export async function getStaticPaths() {
2
    const posts = await getSortedPosts();
3

4
    // 只传递必要的导航数据
5
    return posts.map((entry) => ({
6
        params: { slug: entry.id },
7
        props: {
8
            slug: entry.id,
9
            prevSlug: entry.data.prevSlug,
10
            prevTitle: entry.data.prevTitle,
11
            nextSlug: entry.data.nextSlug,
12
            nextTitle: entry.data.nextTitle,
13
        },
14
    }));
15
}
16

17
// 在渲染时按需获取完整内容
18
const { slug, prevSlug, prevTitle, nextSlug, nextTitle } = Astro.props;
19
const entry = await getEntry("posts", slug);
20
const { Content } = await render(entry);

这个优化将 getStaticPaths 阶段的内存占用减少了 90% 以上。

2. 增加 Node.js 内存限制#

1
{
2
  "scripts": {
3
    "build": "NODE_OPTIONS='--max-old-space-size=7168' astro build"
4
  }
5
}

Node.js 默认堆内存限制约 2-4GB，显式设置为 7GB 可以充分利用 Vercel 的 8GB RAM。

3. 限制构建并发#

1
export default defineConfig({
2
    build: {
3
        concurrency: 2,  // 限制并发构建
4
    },
5
});

有趣的是，测试发现 concurrency: 2 比无限制更快：

concurrency: 2：2m 19s ✅
无限制：3m 45s ❌

过多并发会导致资源竞争，反而变慢。

测试方法：

首先concurrency: 2
运行构建并计时
先增加到4，再增加到6，最后增加到8
使用最快设置
重要提示：并非越多越好！案例研究发现，在12核系统中，4个CPU是最佳选择。

4. 禁用 HTML 压缩#

1
export default defineConfig({
2
    compressHTML: false,  // 让 CDN 处理压缩
3
});

CDN 使用 Brotli 压缩（比 gzip 更高效），本地 HTML 压缩的收益被覆盖，不如省下这部分内存和时间。

5. 升级构建目标#

1
// astro.config.mjs - vite 配置
2
vite: {
3
    build: {
4
        target: 'es2022',  // 减少代码转译
5
    },
6
}

6. 修复 Expressive Code 重复主题#

1
// 修复前（bug）
2
themes: [theme, theme],  // 重复了
3

4
// 修复后
5
themes: [theme],

优化效果#

指标	优化前	优化后
构建结果	OOM 失败	成功 ✅
构建时间	-	2m 19s
内存占用	超过 8GB	正常范围

总结#

对于大规模 Astro 博客的构建优化，最重要的是：

getStaticPaths 只传递必要数据 - 这是核心优化
合理的并发限制 - 不是越多越好
利用 CDN 压缩 - 本地压缩可以省略
充分利用可用内存 - 设置 NODE_OPTIONS

这些优化不仅解决了 OOM 问题，还让构建更快更稳定。