NocoBase 2.0 beta自动更新实战：从Git拉取到PM2重启的完整方案

最近把 NocoBase 2.0 beta 的 next 分支拉到了自己的开发服务器上，然后顺手配了一套“每天自动更新 + 自动编译 + 自动重启”的流水线。Git 拉代码本身不难，难的是怎么让这个“beta 追新”的过程不折腾人：既不会因为半夜更新失败把服务搞挂，也不会因为第二天早上发现数据库迁移没跑完而一脸懵。这篇文章就是把我踩过的坑、验证过的方案完整写出来，适合正在用 NocoBase 做项目、又希望早点体验 2.0 新特性的开发者参考，也适合想把自己的开源项目做成“每日自动滚动更新”模式的朋友照搬思路。

先说清楚这套流程到底解决什么问题。NocoBase 的 2.0 目前处于 beta 阶段，核心功能每天都在动，next 分支就是开发主干，上面有最新的数据库设计、插件体系和工作流引擎。你手动 git pull 一次两次没问题，但要天天盯着它改了什么、什么时候需要重新编译，那就很痛苦了。更麻烦的是 NocoBase 的构建产物不是拷贝就完事，它涉及依赖安装、前端构建、数据库迁移、服务重启这几个环节，任何一个环节出错，服务就会起不来。我做的这套自动化，就是用脚本把“拉取-安装-构建-迁移-重启”串起来，再交给 crontab 每天定时执行，配合日志和通知机制，让整个追新过程变成无人值守的例行任务。

1. 为什么要盯 next 分支，以及这套自动化解决的痛点

1.1 NocoBase 2.0 beta 与 next 分支的关系

NocoBase 是一个“积木式”的无代码/低代码平台，它的核心卖点是可以像搭积木一样配置数据模型、页面、权限和工作流。1.x 版本已经比较稳定，但 2.0 对底层做了大量重构，尤其是数据源管理、插件加载机制和前端渲染引擎都换了思路。官方把 2.0 的代码放在两个分支里：main 分支通常对应相对稳定的 release 版本，而 next 分支则是 beta 阶段的活跃开发分支。如果你只想稳定使用，那直接用 release 包就行；但如果你想第一时间看到新功能、参与反馈 bug，或者想提前为项目升级做兼容性测试，那就必须跟 next 分支。

不过 next 分支的特性也意味着它“不清真”：代码可能今天引入了新依赖，明天改了数据库字段，后天又改了环境变量配置。手动更新时最怕的就是这种不确定性，因为你永远不知道这次 pull 下来的代码能不能直接跑起来。所以我会坚持“每天自动更新 + 自动编译 + 自动重启”这套闭环，至少保证每天有一个确定性的检查点。哪怕某天构建失败了，我也能通过日志和通知第一时间知道，而不是等到手动打开页面才发现服务已经挂了一夜。

1.2 手动拉取更新的日常噩梦

在没有自动化之前，我的更新流程是这样的：先在服务器上执行 git pull origin next，然后看它有没有新版本；接着运行 yarn install 或 pnpm install 安装新依赖；然后执行前端构建；最后重启服务。听起来简单对吧？实际上每一次都像开盲盒。NocoBase 2.0 的依赖树非常庞大，光是 install 就可能要跑好几分钟，构建也可能因为版本不匹配而失败。更痛苦的是，如果你只更新了后端代码而忘了重新构建前端，页面会显示一堆白屏和路由错误；如果你更新了数据库相关代码却忘了执行迁移命令，登录页直接报 500。

这些操作集中在白天做，会把你从开发状态中硬生生拉出来；放在晚上做，又可能因为没人盯着而失败。我之前就遇到过这种情况：凌晨两点 cron 跑完，服务正常运行，但第二天早上我发现数据库迁移其实没有真正执行成功，因为脚本里漏了一步。后来我重新设计了脚本结构，把每个阶段单独拆开，任何一个阶段失败就停止后续操作并输出明确原因，才算是把这个问题解决了。

1.3 “每天自动更新+自动编译+自动重启”的整体思路

这套机制的整体思路并不复杂，就是四个动作：定时触发、版本更新、构建部署、健康检查。具体到 NocoBase 的场景，它的执行链路是：

1. 每天凌晨定时从远程仓库拉取 next 分支最新代码；
2. 对比本次拉取是否有更新，没有更新就直接退出，避免空跑；
3. 安装新依赖（如果有 package.json 或 lockfile 变化）；
4. 执行前端构建和后端编译（NocoBase 2.0 使用 pnpm workspace + tsc 的混合模式）；
5. 执行数据库迁移；
6. 重启 PM2 进程；
7. 检查服务是否健康（比如请求一个内部接口或检查端口进程）；
8. 把结果写入日志，并通过 webhook 推送到手机。

这套流程里最重要的是“失败即停止”和“结果可追溯”。你宁可让它停下来等你去处理，也不要让它带着半残的状态硬跑。比如依赖安装失败还继续构建，只是浪费时间；但数据库迁移失败还重启服务，就可能把生产数据搞出问题。所以我后面在脚本里加了严格的阶段控制和退出码判断，任何非零退出码都会中止任务并发送告警。

2. 环境准备：Git、Node、包管理器与进程守护

在开始写自动更新脚本之前，先把服务器上的基础环境搞定。很多人忽略这一步，直接在默认环境上就跑，结果遇到一堆权限、版本、路径问题。我自己在配置过程中也踩了不少坑，这里把关键点列出来。

2.1 Git 安装与 SSH 免密配置

服务器上肯定要有 Git，如果你的发行版没预装，直接安装就行。Debian/Ubuntu 系列用 apt install git，CentOS/RHEL 系列用 yum install git。装完之后最好确认一下版本，git --version 至少要 2.x，太老的版本在处理分支和子模块时会有兼容性问题。

然后是最关键的 SSH 免密配置。自动更新脚本要在 crontab 环境里执行 git pull，而 crontab 的环境跟手动登录 shell 不一样，它不会主动加载你的 SSH agent 和密钥。所以不能依赖 ssh-agent，要把 SSH 密钥直接配成免密能访问 Git 仓库的状态。我习惯的做法是：在服务器上生成专用部署密钥（最好和日常开发密钥分开），然后用该密钥去 Git 平台添加 Deploy Key。比如码云、GitHub、GitLab 都支持单个仓库的部署密钥，这样可以限制密钥权限，即使泄露也只会影响到这一个仓库。

生成密钥的命令是 ssh-keygen -t ed25519 -C "deploy@nocobase"，一路回车生成在 ~/.ssh/id_ed25519。然后要把公钥内容加到目标 Git 平台对应项目的 Deploy Keys 里。配置完成后，用 ssh -T git@gitlab.com 或者对应平台的测试命令验证连接。如果服务器上有多个仓库多个密钥，可以在 ~/.ssh/config 里给每个主机指定 IdentityFile，这样 git pull 时就能自动匹配正确的密钥。额外说一句，不要在脚本里用 GIT_SSH_COMMAND 明码写密码，也不要把账号密码放进远程地址，否则会有安全风险，而且 crontab 进程的命令行参数是全用户可见的。

2.2 Node 版本与 pnpm/yarn 的选择

NocoBase 2.0 对 Node 版本有明确要求，beta 阶段通常要求 Node 18 以上，有些新特性可能还要求 20。建议使用 nvm 或直接安装最新 LTS，然后固定主版本。千万不要在服务器上默认 Node 版本太老，否则构建时会看到一堆 ERR_REQUIRE_ESM 之类的报错。我用的是 Node 20 LTS，实测兼容性没问题。

包管理器方面，NocoBase 2.0 官方倾向 pnpm。因为 2.0 重构后采用 pnpm workspace 管理多包仓库，根目录的 package.json 里会声明 packageManager。如果你用 yarn 1.x 去安装，很可能会因为 workspace 协议解析方式不同而装出完全错误的依赖树。这是非常常见的坑。所以直接用 pnpm，安装命令就是 corepack enable 之后用 pnpm install。如果你以前只用过 npm，刚开始会觉得 pnpm 有点不习惯，但它的硬链接机制在高频安装大依赖时特别有用，能省很多时间。

还有一点，pnpm 对磁盘空间需求比较大，如果服务器是低配 VPS，注意不要把所有依赖都怼到系统盘。我自己是把 NocoBase 项目放在独立数据盘上的，然后用 pnpm store path 查看存储位置，必要时通过 pnpm config set store-dir 改到另一个磁盘。

2.3 PM2 或其他进程守护方案

NocoBase 2.0 通常用 yarn start 或者 pnpm start 启动，开发时可以直接前台跑，但作为长期运行的服务，必须要有进程守护。PM2 是我用得最多的方案。安装 PM2 也很简单，npm install -g pm2。然后在项目根目录用 pm2 start 启动，也可以直接在启动命令里指定脚本名，比如：

bash复制pm2 start "pnpm start --port=13000" --name nocobase

PM2 的好处是可以设置开机自启、自动重启、保存进程列表、查看日志。对于自动更新场景，我们还会在脚本里使用 pm2 reload nocobase 或 pm2 restart nocobase。这里要注意 reload 和 restart 的区别：reload 会触发优雅重启，让旧进程处理完已有请求再切到新进程，适合在线服务的零中断发布；restart 是直接强行重启。如果构建和迁移都成功了，优先用 reload，避免把正在使用的用户请求断掉。不过 NocoBase 部分版本里，reload 可能会因为连接池未释放而出现端口占用问题，如果你是单人开发机，直接用 restart 也没问题。

除了 PM2，也可以用 systemd 服务脚本，但 PM2 对于多环境日志管理更省心，尤其是实时查看 pm2 logs 很方便，所以我还是推荐 PM2。

2.4 初始拉取 next 分支

基础环境弄好之后，先把仓库克隆下来。假设你的代码托管在 Git 平台，项目地址类似 git@git.example.com:group/nocobase.git。在服务器目标目录下执行：

bash复制git clone git@git.example.com:group/nocobase.git
cd nocobase
git checkout -b next origin/next

如果之前已经克隆过别的分支，可以用：

bash复制git fetch origin
git checkout next
git pull origin next

初始拉取完成后，建议先手动跑一次完整的 pnpm install && pnpm build && pnpm start，确认能正常启动，然后再去做自动化。不要跳过这一步，否则你可能把一套根本不工作的代码挂在 crontab 里天天重试。手动跑通之后，再看后续自动化脚本，心里就有底了。

3. 自动更新脚本的完整实现

这一部分是全文的重头戏。自动更新脚本我放在项目目录外的独立目录里，比如 /opt/nocobase-update/update.sh，这样避免被 Git 仓库的 .gitignore 影响，也方便单独维护权限。脚本要支持手工执行，也可以被 crontab 调用。下面逐步拆解。

3.1 脚本逻辑框架

整个脚本的核心逻辑可以概括为：准备环境、拉取更新、判断变化、安装依赖、构建编译、数据库迁移、重启服务、健康检查、结果通知。先给出一个简化版框架：

bash复制#!/usr/bin/env bash
set -euo pipefail

# 配置区域
PROJECT_DIR="/data/nocobase"
LOG_FILE="/data/nocobase-update/update-$(date +\%Y\%m\%d).log"
# 其他配置

update() {
    echo "[$(date '+%F %T')] ====== 开始自动更新 ======" >> "$LOG_FILE"
    cd "$PROJECT_DIR"

    # 1. 拉取最新代码
    git fetch origin next
    git reset --hard origin/next  # 注意：这样会丢弃本地改动，需要确认
    echo "[$(date '+%F %T')] 拉取代码完成" >> "$LOG_FILE"

    # 2. 安装依赖
    pnpm install >> "$LOG_FILE" 2>&1

    # 3. 构建
    pnpm build >> "$LOG_FILE" 2>&1

    # 4. 数据库迁移
    pnpm nocobase migrator up >> "$LOG_FILE" 2>&1

    # 5. 重启服务
    pm2 restart nocobase >> "$LOG_FILE" 2>&1

    # 6. 健康检查
    curl -fsS http://127.0.0.1:13000/api/health >> "$LOG_FILE" 2>&1

    echo "[$(date '+%F %T')] ====== 更新成功 ======" >> "$LOG_FILE"
}

update

这是理想状态，但实际使用中不能这么粗暴。git reset --hard 会丢掉所有本地改动，如果你的 env 文件或 storage 目录被追踪了，就会出大问题。所以真实的脚本要做更多判断和备份，下面拆开讲。

3.2 每一步的细节：拉取、安装、构建、迁移、重启

git pull 还是 git reset --hard？

自动更新时最大的问题是本地代码与远程代码不一致。如果你的服务器只是部署环境，没有在源码上做任何改动，那 git reset --hard origin/next 是最干净的方案，它可以保证本地和远程完全一致，避免因为本地文件残留导致构建环境不一致。但前提是：你需要把自己定制的配置文件放在 Git 忽略的目录里，比如 .env 和 storage/。NocoBase 的配置通常是用 .env 文件管理的，而 .env 默认不进版本库。我在脚本里用了 git reset --hard 后，还会额外执行 git clean -fd 来清理未追踪文件，但这样会把一些临时缓存目录也删掉，所以我只对 packages、apps、node_modules 这种目录用，或者干脆不做 git clean。更保险的做法是：先 git stash 本地修改，再 git pull --rebase，但这种方式在多人协作时容易产生大量冲突，自动处理很难。最终我是这样写的：

bash复制git fetch origin next
git reset --hard origin/next
git clean -fd -e .env -e storage -e node_modules

git clean 的 -e 参数用于排除你不想删除的内容。加上 node_modules 排除是因为后面 pnpm 会重新安装，没必要现在删；.env 和 storage 必须保护，否则数据库连接和上传文件全没了。

依赖安装：

NocoBase 2.0 的依赖安装命令和 1.x 不太一样。经过我的实测，官方推荐的流程是：

bash复制pnpm install

如果你看 package.json 里有很多 workspace 依赖，那 pnpm install 会一次性把 packages/* 下所有子包的依赖都装好。但有时候锁文件没更新，可能 pnpm install 并不会安装最新版的传递依赖，这时候需要连 pnpm install --force 一起考虑。不过 --force 会强制重新解析所有依赖，比较耗时，建议只在发现依赖异常时用。为了加快速度，我加了 --frozen-lockfile=false 允许更新锁文件，但要注意如果远程代码改了 lockfile，那这个东西就看你能否接受锁文件漂移。更稳妥的做法是不要加参数，直接用默认 pnpm install。

构建：

NocoBase 2.0 的构建命令比较重。根目录执行 pnpm build 会先构建核心包，再构建插件和前端资源。整个过程可能持续 5~10 分钟，在低配机器上甚至更久。构建失败的原因通常是某个依赖版本不对或 TypeScript 类型不兼容，日志里会明确报错。这里关键点是不能让构建脚本后台运行或者丢弃错误，一定要把 stdout 和 stderr 都重定向到日志文件，并检查退出码。我在脚本里会这样写：

bash复制if ! pnpm build >> "$LOG_FILE" 2>&1; then
    echo "构建失败，停止更新流程" >> "$LOG_FILE"
    exit 1
fi

数据库迁移：

NocoBase 2.0 的数据库迁移命令变化过几次。早期在 1.x 中是 yarn nocobase migrator up，2.0 beta 中 cli 可能变成了 pnpm dlx nocobase migrator up 或者 pnpm nocobase migrator up。更稳妥的方法是读一下 package.json 中的 scripts 定义，看看官方有没有提供 migrate 或 migrator 脚本。我最终使用的是：

bash复制pnpm nocobase migrator up >> "$LOG_FILE" 2>&1

如果迁移失败，日志里会显示具体是哪个迁移文件、哪张表、哪个字段出了问题。这时候绝对不能重启服务继续跑，因为数据库 schema 处于半迁移状态，服务起来后可能频繁报错。我会让脚本直接中断，并发送告警。

重启服务：

上面提到的 PM2 重启命令：

bash复制pm2 restart nocobase

但要注意 PM2 的环境变量。crontab 里跑的脚本，PATH 环境可能不包含 /usr/local/bin，而 pm2 和 pnpm 都是全局安装到那个目录的。所以我通常在脚本第一行就导出 PATH：

bash复制export PATH="$PATH:/usr/local/bin:$HOME/.nvm/versions/node/v20.12.0/bin"

不确定路径时，可以先手动执行 which pm2 和 which pnpm，把路径填进去。如果 PM2 是用 npm 全局装的，那么 pm2 命令在 crontab 中经常失效，这是个高频坑。

3.3 版本比对与空更新跳过

如果每天都跑，其实很多天 next 分支都没有新提交。这时候没必要重新安装、构建一遍，白白浪费 CPU 和流量。所以脚本应该判断是否有更新。实现方式很简单：git fetch 后，比较本地 HEAD 和远程 origin/next：

bash复制git fetch origin next
LOCAL_REV=$(git rev-parse HEAD)
REMOTE_REV=$(git rev-parse origin/next)
if [ "$LOCAL_REV" = "$REMOTE_REV" ]; then
    echo "无新版本，跳过" >> "$LOG_FILE"
    exit 0
fi

这里先记录 LOCAL_REV，再 git reset --hard origin/next，然后 echo "$LOCAL_REV -> $REMOTE_REV" 写入日志，便于回溯。

另外，NocoBase 的版本号在 next 分支上是跟随提交走的，没有固定版本号，但你可以通过 git log --oneline -1 记录当前提交 hash，方便知道某天的服务是基于哪个 commit 构建的。这个信息很有用，当服务出问题时，你能准确说“我跑的是 2025 年 6 月 1 日的某个 commit”。

4. Crontab 定时任务与日志、通知

脚本写好后，剩下就是定时执行和结果反馈。

4.1 crontab 配置与时间点选择

编辑当前用户的 crontab 用 crontab -e，加入一行：

bash复制20 4 * * * /usr/bin/bash /opt/nocobase-update/update.sh >/dev/null 2>&1

时间点选在凌晨 4:20，很多人喜欢 3~5 点之间，原因是不影响白天使用，而且这个时段上游数据库和构建服务器压力较小。但要注意：如果你的服务器时区不是本地时间，crontab 默认用的是系统时区，记得先 date 确认时间，或者用 CRON_TZ=Asia/Shanghai 指定时区。我踩过这个坑，最开始没注意服务器是 UTC 时间，结果脚本每天都在北京时间中午 12 点跑，搞得服务莫名其妙重启一次。

还有一点，> 重定向到 /dev/null 只把 stdout 丢了，日志文件还是会在脚本内部写入。所以上面那行不会影响日志。如果你希望 crontab 自己的输出也保留，可以重定向到另一个文件。

4.2 日志输出与轮转

日志文件如果用日期命名，比如 update-20250602.log，每天一个文件，就不需要轮转脚本。但要注意磁盘空间，如果构建日志非常详细，一个文件也能轻松到几百 MB。我一般只保留最近 14 天日志，用 find 命令在脚本末尾清理：

bash复制find /data/nocobase-update -name "update-*.log" -mtime +14 -delete

如果希望日志更紧凑，可以在构建命令后加 tail -n 50 只输出末尾摘要。不过查问题的时候往往需要完整日志，所以我建议保留全量日志，清理周期设短一点。

日志内容建议除了命令输出外，再额外记录几个关键信息：更新开始时间、结束时间、本地/远程 commit hash、更新结果、健康检查的响应内容。这些信息写在一个专用 summary 文件里，方便每天翻一眼。比如：

bash复制echo "日期：$(date '+%F')"
echo "提交：$LOCAL_REV -> $REMOTE_REV"
echo "构建时长：$(( (END_TIME - START_TIME) / 60 ))分钟"
echo "结果：SUCCESS"

4.3 结果通知：Webhook 推送

日志是给人看的，但每天主动去翻日志也很烦。我更推荐配合 webhook 把结果推到手机。最简单的是企业微信机器人、钉钉机器人或 Slack 通知。以钉钉为例，你在移动端创建一个自定义机器人，得到一个 webhook URL，然后在脚本成功或失败时用 curl 发一个文本消息。我写了一个函数：

bash复制notify() {
    local message="$1"
    curl -fsS -H "Content-Type: application/json" \
        -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$message\"}}" \
        "$WEBHOOK_URL" >> "$LOG_FILE" 2>&1
}

成功时发一条“NocoBase 更新成功，commit xxx”，失败时发“NocoBase 更新失败，请查看日志 /data/nocobase-update/……”并带上错误关键词。这样每天早上醒来第一件事就是看手机，不用 ssh 上服务器，既方便又安心。

如果不想依赖第三方机器人，也可以写一个极简的邮件发送脚本，或者直接用 pm2-logrotate 自带的日志压缩。但 Webhook 是我用过最轻量、最不折腾的方案了。

5. 常见问题与排查技巧实录

自动更新这套玩意，不跑一段时间你是不知道坑在哪里的。下面这些是我在维护过程中真实遇到过、也排查过的问题，整理成速查表，希望对你有帮助。

5.1 git pull 冲突与本地修改被覆盖

自动更新脚本里，git reset --hard 和 git clean -fd 是双刃剑。优点是绝对保持代码纯净，缺点是如果有未提交的本地修改会被静默删除。我在某次维护时，因为临时改了一个插件包的代码来调试问题，结果自动更新跑完，改动全部没了，还以为是别人动了我代码。后来我规定：任何调试修改都必须 commit 到一个单独的本地分支，不要留在工作区。如果你不想完全强制覆盖，可以把 git reset --hard 换成：

bash复制git diff --quiet || git stash
git pull --rebase origin next

但如果远端做了一次强推或 rebase，你本地基于旧 commit 的 rebase 会失败，自动化就卡住了。所以我最后还是选择强覆盖，然后靠备份保护核心配置。有一点必须说：storage/ 目录如果被 Git 追踪，千万别 git clean -fd 无差别清理，否则上传的文件、备份的数据全没了。这也是我把 storage 写成排除项的原因。

5.2 依赖安装失败、幽灵依赖与回退

NocoBase 2.0 的插件系统非常依赖 pnpm 的 workspace。如果你之前用 npm 或 yarn 安装过，会在 node_modules 里留下很多非 pnpm 结构的文件，导致后续构建时从根目录找不到子包的依赖，这就是常见的“幽灵依赖”问题。遇到这种问题，我推荐三步走：

bash复制rm -rf node_modules packages/*/node_modules
pnpm install --force
pnpm build

不要怕删除 node_modules，pnpm 有 store 层缓存，重装速度快很多。如果是网络源的问题导致 install 失败，可以临时改用镜像源。设置方法是在项目根目录 .npmrc 里加一行 registry=https://registry.npmmirror.com。但注意，NocoBase 官方有些私有包可能只在官方源发布，切换镜像可能出现 404，需要具体看报错。

5.3 数据库迁移失败与回滚策略

自动更新里最危险的就是数据库迁移。一旦迁移脚本有 bug，你可能面对一张 bad schema 的数据库。我的建议是：在自动更新前先备份数据库。NocoBase 的数据库可能是 SQLite 文件，也可能是 PostgreSQL 或 MySQL。如果是 SQLite，直接复制文件备份：

bash复制cp data.db data-$(date +%F).bak

如果是 PostgreSQL/MySQL，用 pg_dump 或 mysqldump 备份。备份完成后再跑迁移。迁移失败时，不要急着重启服务，应该先查看迁移日志，找到失败原因，确实解决不了就用备份恢复。恢复数据库后，同时把代码回退到上一个 commit，这样才能保证代码和 schema 匹配。我把回滚逻辑也写进脚本了，但只在检测到迁移失败时自动执行一次“代码回退 + 依赖回装 + 重启”，这个操作要谨慎，一不小心会把数据库搞坏。如果小组件不复杂，还是先停下等人工处理。

5.4 PM2 日志爆掉与内存占用

PM2 默认会记录标准输出到日志文件，NocoBase 启动后可能输出大量请求日志、调试日志，尤其是 next 分支的 beta 代码，有时会循环打印错误堆栈。时间长了，PM2 的日志文件能到好几个 GB。我装了一个 pm2-logrotate 模块：

bash复制pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 100M
pm2 set pm2-logrotate:retain 7

这样日志超过 100MB 就自动 rotate，保留 7 份。另外 PM2 本身也会占用内存，2.0 的 node 进程如果内存异常增长，可以在 ecosystem 配置文件里加上 max_memory_restart: "800M"，让 PM2 在内存超过阈值时自动重启。这对于开发服务器来说很省心。

5.5 构建失败但不影响旧服务运行

自动更新的初衷是不能把好端端的服务搞挂。但脚本执行过程中，如果你先停服务再构建，后续构建失败就会让服务直接停止；所以更好的顺序是：先构建，成功后重启。我最初的脚本就是在构建前把服务停了，结果某次构建失败，导致服务停了半天没有人发现。后来我把顺序调整成“先构建，后重启”，构建期间旧服务继续跑，只有构建成功才重启，这样服务可用性高很多。唯一的弱点是构建期间会消耗 CPU 和内存，可能影响线上请求质量，但对于个人开发服务器问题不大。

6. 给自动化加一点“自我保护”：健康检查与失败告警

前面讲了很多，但真正让这套系统可落地的，是健康检查和失败告警。构建成功不代表服务能起来，迁移成功也不代表页面能正常响应。所以脚本最后一定要有健康检查环节。

NocoBase 2.0 本身提供一个健康检查接口，我是在根目录的 packages/core/server/src 里找到的，默认路径一般是 /api/health。用 curl 请求：

bash复制HTTP_CODE=$(curl -s -o /tmp/nocobase-health-response -w "%{http_code}" http://127.0.0.1:13000/api/health)
if [ "$HTTP_CODE" != "200" ]; then
    echo "健康检查失败，HTTP $HTTP_CODE" >> "$LOG_FILE"
    notify "NocoBase 更新后健康检查失败"
    exit 1
fi

如果你不确定健康检查路径，可以改用 curl -I 检查首页是否返回 200，或者用 pm2 jlist 检查进程状态是否为 online。更精确的方法是用 node 脚本直接请求一个登录接口，看是否能返回预期的 JSON。不过 beta 版本接口变动频繁，我建议用最基础的 /api/health，或者干脆用 lsof 检查端口监听都行。我自己甚至加了一个“二次确认”：健康检查成功后再过 30 秒检查一次进程是否仍然存活，防止进程启动后又崩溃。

另外，通知时机也很讲究。我是在以下三种情况下发通知：更新成功时发一条轻量消息；更新失败时发一条详细告警；连续两天无新版本时不发消息，免得刷屏。如果脚本因为某种原因没有执行成功，crontab 不会产生任何日志，这时候只能靠失败通知或心跳检测发现。更稳一点可以再加一个“心跳文件”，比如每次执行都在 /tmp/nocobase-update-heartbeat 里打个时间戳，然后用外部监控（比如 uptime 机器人）检查这个文件是否更新，这样比单纯看日志更可靠。

最后再分享几个亲测有效的细节

先说说我自己实测下来最顺手的组合：git reset --hard origin/next + git clean -fd -e .env -e storage && pnpm install && pnpm build && pnpm nocobase migrator up && pm2 reload nocobase。这套组合在 NocoBase 2.0 beta 的 next 分支上已经连续跑了快两个月，大多数时候每天早上 5 点前静默更新完成，偶尔有一两次失败也都是数据库迁移问题，基本都能通过日志快速定位。

有几个细节点我再强调一下。第一，脚本里的时间戳一定要带上 %F %T，不要只用 date，否则同一个文件里没法判断先后顺序。第二，日志文件不要直接放在项目目录里，否则 git clean 会搞出麻烦事，我在脚本中把日志目录单独放在 /data/nocobase-update，这样无论 Git 怎么清，日志都不会被动。第三，PM2 的 pm2 startup 一定要设置，否则服务器重启后 PM2 不会自动拉起 NocoBase，那你的自动更新就失去依托了。第四，如果哪天脚本因为权限问题不执行，第一反应是检查 crontab 的环境变量而不是脚本逻辑，最常见错误就是 PATH 里没有 pnpm 路径。

另外，如果你打算长期跟踪 next 分支，最好在服务器上建立一个“更新历史”文本文件，每次更新后把 commit hash 和更新摘要写进去。这样当你在使用某个功能时发现 bug，可以快速知道这个 bug 是哪个提交引入的，也方便在 issue 里给官方反馈。我个人习惯是每周日把本周的更新历史导出，和 NocoBase 官方 changelog 对照一遍，看看有没有需要注意的 breaking change。

这套自动化思路肯定不是唯一方案，你可以根据自己的实际场景改：比如把定时任务改到每周跑一次，或者加入 git tag 判断仅在发布标签时更新，都没问题。但只要把“拉取-安装-构建-迁移-重启-检查-告警”这一套闭环做扎实，无论是追 NocoBase 2.0 beta 还是其他活跃开源项目，你都能获得一个相对稳定的“自动追新”体验。我目前还在逐步完善的就是把每次构建产物做一次缓存，这样当它更新后又回滚时能少一次全量编译。如果你也在折腾 next 分支的自动更新，希望这篇能帮你少走些弯路。