Next.js 本地开发优化：解决 HMR 资源占用问题

如果你用 Next.js 搭建了一个博客，内容全在 content/ 目录下，那么本地开发写文章时你大概率会遇到：机器风扇狂转、磁盘读写拉满、编辑器都卡得不行。

我在用的版本

• Next.js-16.x
• next-remote-watch-2.0.0

# 问题出现

某天在本地写博客，发现机器突然变得很卡。打开活动监视器一看，node 进程 CPU 占用很高，磁盘读写也异常活跃。

而此时我只是在编辑一个 .mdx 文件而已。

# 如何排查

# 确认是不是 next dev 的问题

先停掉 next dev，再看资源占用 —— 立刻恢复正常。重新启动 next dev，问题复现。

# 找到根因

Next.js 的 dev 模式默认会监控整个项目目录的文件变化，以实现 HMR（Hot Module Replacement）。在默认的 Webpack 模式下，Next.js 会通过文件系统监听（fs.watch / chokidar）来感知文件变更。

问题在于，一个典型的 Next.js 项目结构长这样：

.
├── content/          # 你的博客文章
├── src/
│   ├── app/
│   ├── components/
│   ├── lib/
│   └── styles/
├── node_modules/     # 被 ignore 了，但还是要过滤
├── .next/            # 构建产物，频繁写入
├── package.json
└── next.config.ts

当你在写文章编辑 content/xxx.mdx 时，Next.js 不仅监听到了这个文件的变化，还在持续监听 src/、.next/ 以及项目中所有其他文件。加上 HMR 触发的重新编译、模块替换，磁盘和 CPU 就被打满了。

尤其是博客场景，大多数时候你只在改 content/ 下的文章，根本不需要 HMR 去关心 src/ 下的代码变化。

# 解决方案：next-remote-watch

next-remote-watch 是 HashiCorp 开源的一个工具，思路很直接：替换 next dev 默认的文件监听机制，只监听你指定的路径。

# 安装

npm install next-remote-watch --save-dev

# 配置

在 package.json 中新增一个 edit 脚本：

{
  "scripts": {
    "dev": "next dev",
    "edit": "next-remote-watch ./content"
  }
}

默认的 dev 保留不动（开发代码时用），edit 是写文章时专用 —— 只监控 content/ 目录。

# 使用

写文章时运行：

npm run edit

它和 next dev 一样会启动开发服务器并打开 localhost:3000，区别在于它只监听 content/ 下的文件变化。修改 src/ 下的代码不会触发任何 HMR。

# 运行效果对比

# 它是怎么做到的

next-remote-watch 启动后会：

1. 启动 next dev 作为子进程
2. 劫持 Webpack/Turbopack 的文件监听，通过环境变量让 Next.js 不再自己监听文件
3. 自己用 chokidar 只监听指定目录（比如 ./content），当文件变化时，通过 Next.js 的 HMR WebSocket 通道发送一个事件过去，触发页面热更新

这样就把文件监控的范围从「全项目」缩小到「一个目录」，资源占用自然大幅下降。

# 总结

这个问题本质上是 Next.js 默认行为与博客场景不匹配：

1. Next.js 默认监控全项目 — 适合开发应用代码
2. 博客场景只需要监控内容目录 — 编辑文章不需要触发组件重新编译
3. next-remote-watch 只监控 content 目录 — 磁盘 I/O 和 CPU 占用显著降低
4. 保留原生 next dev — 开发代码时照常用，两者不冲突

两个命令各司其职，写代码用 npm run dev，写文章用 npm run edit，完美解决。

# 参考链接

• next-remote-watch - GitHub