Next.js 构建突然卡壳？这 4 个原因最常见
凌晨 2 点，周五。你的 Next.js 构建——上周还要 45 秒——现在要 8 分钟。CI/CD 管道在烧时间，测试环境部署卡住了，你睡不着觉试图弄清楚为什么。昨天还好好的。
这正是”上周还能用”变成你最讨厌听到的话的那一刻。
构建变慢不是罕见现象——它是代码库增长的必然。但它也是可以解决的。下面是四个常见元凶和对应的杀招。
四大构建杀手
1. 你不知道自己加的依赖
Next.js 的构建速度完全取决于最重的那个依赖包。一个看似无害的”助手库”引入 lodash、moment.js 或臃肿的图表库，就能让构建时间暴增 30–60 秒。更糟的是：如果新依赖出现在 node_modules 里，webpack 会处理它——无论你是否真的用它。
查看依赖树：
npm list --depth=0
找出重复的包。如果看到 npm WARN 警告同一个包有多个版本，webpack 就会处理两次代码。这是每次构建都在浪费 CPU 时间。
2. 内存耗尽
Node.js 默认堆内存限制约 2.2 GB。随着代码库增长，构建过程需要内存来做源码解析、AST 转换、树形摇动分析和代码分割。一旦超出限制，Node 就会进入疯狂的垃圾回收模式，一切都变慢。
构建日志里会显示长时间的无输出暂停，或者出现”JavaScript heap out of memory”错误。
3. 缓存污染
Next.js 在 .next/ 文件夹里缓存构建产物。被污染或陈旧的缓存会拖累每一次后续构建。一个遗留的大图片、字体或编译块会迫使 Next.js 重新验证和重建不该动的东西。数个月积累的构建数据 = 每次构建浪费的秒数。
4. Webpack 配置漂移
如果你自定义了 next.config.js（自定义加载器、插件、优化规则），任何配置错误都会级联放大。一个本该只作用于部分文件的加载器反而作用于所有文件，或者插件重复运行不必要的转换，每个文件都会多花秒数。有 500+ 个组件文件的话，秒数会翻倍。
5 分钟诊断清单
按顺序运行下列检查：
-
检查构建时间变化：对比今天的构建时间和上周的日志。如果超出 50%，说明最近加了什么东西。
-
测试无缓存构建：
rm -rf .next && npm run build。如果无缓存版本仍然要 8 分钟，问题在你的代码或依赖，不是缓存。 -
内存分析：
node --max-old-space-size=4096 node_modules/.bin/next build。分配 4 GB 内存重试。如果突然 90 秒完成，说明 Node 内存饥饿。 -
检查新包：
git log --oneline -20 | grep -i package。看过去几天有没有人加依赖。 -
检查缓存：
ls -lh .next/。超过 100 MB 的文件需要怀疑。.next/整个文件夹不应超过 500 MB。
立竿见影的修复
立即 (接下来 10 分钟)：
- 清空缓存：rm -rf .next && npm run build
- 增加 Node 堆内存：在 package.json 的构建脚本里加 --max-old-space-size=4096
- 杀掉后台进程：确保 IDE、Docker 或其他应用没有占用资源
本次构建 (接下来 30 分钟)：
- 删除未使用的包：npm prune 并审查 package.json 里的冗余
- 合并重复的包：如果有同一个库的两个版本，合并成一个
- 注释掉实验性配置：查看 next.config.js 里有没有作为”试试看”加的自定义加载器或插件
本周 (预防)：
- 设置构建时间监控：设定阈值（比如超过 3 分钟就失败）。CI/CD 会在问题爆发前告诉你
- 使用动态导入：把重型组件改成 next/dynamic 并用 lazy 加载
- 启用 SWC 压缩：确保 next.config.js 里有 swcMinify: true。它比 Terser 快得多
防止下次发生
- 锁定依赖版本：在 CI/CD 里用
npm ci。在package.json里用精确版本号，不要用^1.2.3这样的范围 - 加 pre-commit 钩子：用
husky拒绝未审查的新包 - 监控构建时间：提交
build-stats.json来追踪趋势。单个 PR 导致 30% 的回归就得调查 - 本地测试构建：推送前运行
npm run build。对你慢的，对 CI 也慢
慢构建的真实代价
慢构建不仅烦人——它会复利： - 部署阻塞：8 分钟构建意味着测试环境每 30 分钟才能更新一次，而不是 5 分钟 - 开发停滞：工程师等待时不能做其他事 - CI/CD 爆炸：20 个工程师 × 每次多花 5 分钟 = 每天团队浪费 ~1.5 小时
对于按期限交付的团队来说，这转化成延期和成本。
如果你在扩展自定义软件并想跳过”诡异卡顿”阶段，Trove Deck Solution 在技术评估阶段会对构建管道进行完整审查。我们在 2 点的危机发生前就把这些瓶颈找出来。预防比救火便宜得多。