NotionNext 升级：我如何在新版本、个人改动和部署稳定之间做取舍

NotionNext 是一个持续维护的项目。

持续维护意味着它会修 bug、加功能、优化性能，也意味着使用者会不断遇到一个现实问题：我要不要升级？怎么升级？升级失败怎么办？

我以前写这篇文章时，重点是 GitHub 页面上怎么点 Fetch upstream，怎么处理冲突，怎么看 Vercel 部署日志。

现在我更想把它重写成一套升级判断框架。

因为真正重要的不是某个按钮，而是我能不能在新版本、个人改动和线上稳定之间保持控制。

我为什么不会盲目升级

升级有价值，但升级不是越快越好。

我会先问几个问题：

新版本解决了我遇到的问题吗；

是否有安全、性能或兼容性修复；

我的主题、配置、环境变量有没有被改过；

这次升级会不会影响线上文章；

失败后能不能回滚；

我有没有时间验证部署结果。

如果只是看到有新版本就点更新，很容易把原本稳定的站点带进不确定状态。

对个人站来说，稳定访问本身就是价值。

我的升级前准备

我会先备份关键配置。

NotionNext 站点通常会改 blog.config.js、主题配置、环境变量、SEO 信息、导航、统计、评论和自定义样式。这些就是我的个人改动。

升级前，我至少要知道：

当前部署分支是哪一个；

当前线上版本是否正常；

自己改过哪些文件；

Vercel 或 Cloudflare 的最近一次部署是否成功；

环境变量是否有记录；

是否能回到上一个 commit。

这些准备不是为了复杂，而是为了让我升级时不慌。

我更喜欢的分支方式

如果只是临时体验，可以直接跟着主分支更新。

但如果这个站点已经承载真实内容，我更喜欢建立自己的部署分支。

例如：

main 用来同步上游版本；

deploy/tangly1024.com 用来保存自己的配置和线上部署；

每次升级时，把上游变化合并到部署分支；

冲突只在部署分支里解决；

部署成功后再继续使用。

这样做的好处是，我不会把上游代码、个人配置和线上部署混在一起。

当冲突出现时，我也能更清楚地判断：哪些是项目更新，哪些是我自己的改动。

冲突出现时，我会怎么处理

冲突不是坏事。

冲突只是 Git 在告诉我：同一个地方，上游改了，我也改了，需要人工判断。

我不会把 Discard commits 当成默认方案。

它有时能快速恢复到上游版本，但也可能丢掉自己长期积累的配置。我的处理顺序是：

先确认冲突文件。

看上游改了什么。

看自己改了什么。

判断哪些配置需要保留。

合并后本地或预览部署验证。

确认线上正常后，再记录这次升级。

如果自己并不熟悉 Git，而站点又很重要，我会选择更保守的路径：先备份配置，再重新 fork 或新建项目，把旧配置一点点迁移过去。

这看起来慢，但更可控。

部署失败时我看哪里

升级完成不等于部署成功。

我会去部署平台看日志。

在 Vercel 里，我会看 Deployments；在 Cloudflare Pages 里，我会看构建记录。真正有用的信息通常在错误日志里：

依赖安装失败；

Node 版本不匹配；

环境变量缺失；

构建命令不对；

主题或配置字段变化；

某个页面数据格式异常。

我不会只盯着浏览器里的白屏。

白屏是结果，构建日志才是线索。

我的升级边界

我对 NotionNext 升级的边界是：

线上站点稳定时，不在没时间验证的时候升级；

升级前备份配置；

不把 token 写进公开仓库；

先看 changelog 或关键提交；

部署后抽查首页、文章页、分类页、搜索和图片；

出问题先回滚，再慢慢分析。

这套边界不是保守，而是为了让个人内容站长期稳定。

内容站如果经常因为升级打不开，读者不会关心原因。他只会记住这个网站不稳定。

这篇旧文现在对我的意义

这篇文章原来是一份升级操作指南。

现在我更愿意把它看成一份长期维护提醒。

个人站不是一次部署完成就结束。它会不断遇到升级、依赖、主题、内容结构和部署平台变化。

我希望自己面对这些变化时，不是凭感觉点按钮，而是有一套稳定流程：

先备份，再理解变化，再合并，再部署，再验证，再记录。

这套流程让 NotionNext 不只是一个博客项目，而是一个可以长期维护的个人内容系统。