在AWS EC2中构建Next.js应用速度极慢且无法完成求助

t2.micro的1核1GB内存是核心瓶颈——哪怕信用规格设为unlimited，内存不足依然会让Next.js构建进程假死，甚至触发OOM（内存溢出）导致实例崩溃，这也是本地构建正常的根本原因（本地内存远高于1GB）。下面是亲测有效的解决方法：

临时添加交换分区（最快速的缓解手段） #

t2.micro默认没有交换分区，内存耗尽后直接卡死。执行以下命令创建1GB交换分区：

# 创建交换文件
sudo fallocate -l 1G /swapfile
# 设置权限避免安全问题
sudo chmod 600 /swapfile
# 格式化交换分区
sudo mkswap /swapfile
# 启用交换分区
sudo swapon /swapfile
# 设置开机自动挂载，重启后生效
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

交换分区能为构建进程提供临时内存缓冲，大概率能让构建完成。

优化Next.js构建参数 #

通过调整构建命令减少资源消耗：

• 跳过代码检查：next build --no-lint，省掉lint环节的CPU占用
• 静态站点用静态导出：如果项目适合静态部署，在next.config.js里设置output: 'export'（Next.js 13+），简化构建流程
• 关闭增量构建：如果开启了增量构建，暂时关闭，避免额外内存开销

临时升级实例规格 #

要是交换分区还是不够，临时升级到t2.small（2核2GB内存）完成构建，之后再降级回t2.micro运行应用——Next.js运行阶段的资源消耗远低于构建阶段，t2.micro足够支撑大部分中小流量应用。

定位具体构建瓶颈 #

执行构建时实时输出日志：next build > build.log 2>&1，卡住时查看日志最后几行，看是否卡在某个页面的静态生成、特定依赖编译环节，针对性优化该页面或替换资源占用高的依赖。

另外，用top命令检查构建时的内存、CPU占用，关闭Amazon Linux上不必要的后台服务，确保资源集中在构建进程上；同时确认Node.js用的是LTS版本，非LTS版本可能存在兼容性或内存泄漏问题。

内容的提问来源于stack exchange，提问作者Tomas Buzeta