之前的机器是 2 核 4g 的配置，打包 nextjs 项目经常不成功，后面升级了 4 核 8G 打包成功了，但是速度很慢，现在好了直接不能打包！
无奈使用免费的 github Actions ，发现吊打阿里云服务器啊，还没一个免费的服务好用！这钱花的不值～
是我不会用阿里云 esc 吗，还是阿里云的 ecs 有猫腻。。。

默认没有 swap 吧，你加个试试看

这个最好排查下，不一定是阿里的问题，有可能你这套打包就是超了 8g 呢。。。我们之前有一个 nuxt 的也是打包内存直接 oom ，现在的前端几十个页面打包时间几分钟内存数 G ，后端数百项 api 打包 20s 内存几百 M ，实在不想吐槽

至于 github ，它的机器确实比较厚道，你的用的实例可能不止 8g

大佬，swap 是什么？我一个小前端不是很懂运维的知识。

是啊，太坑，打包这些都是 next 项目自带的，也问了 AI 有什么优化的方法，最多就是加 node 运行的最大内存还是不行。

＃3 windows 的虚拟内存知道吧，在 linux 上就是 swap

好的，我研究下

打包直接用云效啊，你都用阿里云了为啥不直接用配套的云效流水线。。。

就看在 esc ，ecs 混用的情况，感觉 op 技能还能再提高一些。

GitHub Actions 是 4C16G: docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners

好的，谢谢提醒。

哈哈，是的，不是专业的，只能用的时候网上找找资料，问问 AI

这个就是专业👍

我本地一个 build 完 12MB 的 angular9 的项目，打包的时候吃掉了 2.4GB 内存，再加上你系统其他占用什么的，要是没 swap 的话，超 8G 应该很轻松

前端？

国内各大公有云都有资源 基本官网价格的六折左右都能买到

关于 swap：

Windows 有个功能叫虚拟内存，在磁盘上设定一个文件，当成内存用。当物理内存满了后，就会开始用磁盘上的这个文件。代价是，早期用机械硬盘，速度极慢。但现在 nvme 了，速度很快。

Linux 的 swap ，本质上也是虚拟内存，但是逻辑与 Windows 完全不一样，坑了很多人。swap 是 Linux 主动进行管理，把一小部分不常用的内容放在这里。当物理内存满了后，不一定会使用 swap ，而是会直接 kill 进程。所以经常发现，Linux 物理内存都用完了，swap 却几乎没怎么用。

打包前先设置环境变量

export NODE_OPTIONS=--max_old_space_size=4096

bro, 我自己的定位不是前端，可以把我当成全栈（全干）！虽然从前端入行的。

good, bro.

用了这个配置不行，感觉还是 ecs 服务器太拉垮，准备降低服务器配置了，多花 1000 多块钱很不开心。把这 1000 多去升级宽带更划算。

node 下输入 v8.getHeapStatistics() 看看输出是什么，监控里显示内存只用了 50%，不大可能是 ECS 的问题

v8.getHeapStatistics()
{
total_heap_size: 6516736,
total_heap_size_executable: 262144,
total_physical_size: 6291456,
total_available_size: 2192958816,
used_heap_size: 4726808,
heap_size_limit: 2197815296,
malloced_memory: 262312,
peak_malloced_memory: 172416,
does_zap_garbage: 0,
number_of_native_contexts: 2,
number_of_detached_contexts: 0,
total_global_handles_size: 8192,
used_global_handles_size: 2848,
external_memory: 2293864
}
输出的这些。

heap_size_limit: 2197815296, heap 最大只有 2G ，这个限制没打开

参考 v8 的代码 heap/heap.cc
size_t Heap::HeapSizeFromPhysicalMemory(uint64_t physical_memory) {
// Compute the old generation size and cap it.
uint64_t old_generation = physical_memory /
kPhysicalMemoryToOldGenerationRatio *
kHeapLimitMultiplier;
old_generation =
std::min(old_generation,
static_cast<uint64_t>(MaxOldGenerationSize(physical_memory)));
old_generation =
std::max({old_generation, static_cast<uint64_t>(V8HeapTrait::kMinSize)});
old_generation = RoundUp(old_generation, PageMetadata::kPageSize);

size_t young_generation = YoungGenerationSizeFromOldGenerationSize(
static_cast<size_t>(old_generation));
return static_cast<size_t>(old_generation) + young_generation;
}
默认只能使用 1/4 的物理内存

好兄弟可以了，我之前写了一个 sh 脚本:
log "正在构建项目..."
rm -rf .next/
NODE_OPTIONS="--max-old-space-size=4096" npm run build || handle_error "构建失败"

没加 export 导致的。
这个做备选方案吧，还是 github actions 的自动化部署方案优秀，可以省不少钱。

这和阿里云有屁关系，换到 aws 照样同样的错误

打包这种重复性工作可以考虑用抢占实例，价格便宜，配置可以开高一些

免费打包服务好用那是因为有大佬帮你付了费了，要是换你自己掏钱支付这些 runner 的费用你就知道肉疼了。Github 的收费打包机 2c7g （免费打包机的一半规格）收费价格是每分钟$0.008 ，相当于一天$11.52 ，一个月 300 多美刀。你再和 ECS 的价格比比？

Github Actions 提供的虚拟机配置比较高：Linux 4 核 16 GB 内存 14 GB ssd
性能全面打爆你用的这个 ecs 吧，特别 cpu 配额和 ssd 的 iops

原来如此。

今天刚试了 build 一个 express 项目爆了 heap ，不过我用的是 AWS 的 t2.micro 1C1GB 的丐版配置 😂

抢占的性能突发实例性价比还要更好,开机积分就够打包完成了.

前端代码都干了啥，塞了一个操作系统？

Next.js 项目是这样的，我都不知道塞了什么，上次跑一个 GitHub 上拉下来的服务，我还特地更新了本地 CI 服务器配置。

哈哈，node 项目就这样，npm 包依赖太多

打包的时候要分析几千个模块，nextjs 又要区分哪些页面需要服务端渲染哪些需要 spa 打包，所以页面多了会变慢。我现在用的是 nextjs 是 14 版本，Next.js 15 会好些，默认的打包工具从 Webpack 升级为 Turbopack 。

准备有时间升级 15 版本了，看官方说 15 版本默认使用 Turbopack 了，Turbopack 的速度比 Webpack 快 700 倍，比 Vite 快 10 倍。这使得项目的构建速度大幅提升，开发者可以更高效地进行开发。

有一张很出名的梗图，node_modules 的。。。

借助云效进行打包~

上 swap ，云服务器默认都不开 swap 的，只要内存满了就会挂

比 Vite 快 10 倍笑笑就好

限制一下 nuxt 的并行打包数量应该可以解决

勒索病毒加密了一小时还在加密 node_modules 文件夹那张吗🐶

“全宇宙最重的东西”那张 😂

我自己项目在本地打包, 只推镜像.

要不试试腾讯云这个

好奇问下 为什么会用 nextjs/nuxtjs 这类框架，是确实有 SSR 需求还是其他原因呢

加 swap 管用，一直以为工具有 bug...
sudo fallocate -l 3G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo swapon --show
free -h
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

因为我的项目要做 seo 优化，所以必须用 nextjs 。

啊这。。

👍

next.js 可以配置下 config ，限制下构建内存，不过会比较慢，另外这框架确实很容易内存溢出.. 例如在使用它自身的图片优化服务的时候

你想阿里云 8G 达到 16G 的效果？

前端在构建这一块现在搞得比后端真的是麻烦多了，又大又重

前端太卷了，我平时构建 react 的时候，就感觉相当吃资源，也不理解这里面到底干了啥，以前用 nextjs ，后来换到 vite ，打包速度有提升，打包时候的占用也稍微好一些了

阿里云打包确实慢

前端构建的工具链用 nodejs 的迟早会被淘汰掉，性能太低了。
估计以后都是被 rust 语言重写的工具链替代。

nodejs 赶紧淘汰吧
换个东西来支持 js

啥机型？

开 swap 基本上就能解决了。不过我认为阿里云默认不开 swap 就是故意的，想要一些人傻傻去升级