发版出事怎么办

新版本上线后 5xx 飙升、用户投诉刷进来，第一反应不是登录服务器逐行查日志，更不是急着再发一个修复版——而是先回滚到上一个能用的版本止血，把影响面压住，再慢慢查原因。

服务端回滚：PM2 + 零依赖 server.js

本产品后端就是一个 node server.js，零依赖。回滚本质很简单：每个版本一个目录，用软链接指向当前版本，出问题把链接切回旧目录再重启进程即可。

数据备份与恢复

代码能从 git 回滚，用户数据不行。本产品数据是 JSON 文件（或 SQLite），必须定时备份，且备份文件名带时间戳，恢复时才知道哪个是最新。下面用内存数据模拟「备份→写坏→恢复」全过程。

Capacitor 端：强制更新与服务端回滚配合

服务端回滚后，已经装了新 App 版本的用户可能还在打已经回退的接口。这时服务端可以下发「最低支持版本」，App 启动时发现自己版本太低就弹窗强制升级（或提示回退）。版本号策略以各平台官方最新规范为准。

备份策略：全量 / 增量 / 差异

备份不是「把文件复制一份」这么简单，三个概念要分清。全量备份：每次把整个数据库完整复制一份，恢复最简单，但慢、占空间。增量备份：只备份「上次备份之后变了的部分」，跑得快省空间，但恢复麻烦——要先恢复全量、再依次把每段增量重放。差异备份：备份「上次全量之后变了的部分」，介于两者之间。对本产品这种小 JSON 数据，每天全量一次就够，别上增量把自己绕进去。

RTO / RPO：两个必须背下来的数

出事后跟老板对 SLA，就靠这两个缩写。RTO（Recovery Time Objective，恢复时间目标）：系统最多能忍多久不可用？是 5 分钟还是 4 小时？RTO 决定你要不要做自动故障切换——5 分钟以内你根本来不及手动登录服务器切版本。RPO（Recovery Point Objective，恢复点目标）：最多能容忍丢多久的数据？是 5 分钟还是 1 天？RPO 决定你备份频率——RPO 是 1 小时，你就至少每小时备一次。RTO 管「多久能恢复」，RPO 管「最多丢多少数据」。

数据库备份要停服吗

很多人以为备份数据库必须停服，怕备份过程中数据被写一半。现代数据库（PostgreSQL、MySQL、SQLite）都支持在线热备份：在服务正常运行时做一致性快照，不用停服。SQLite 用 .backup 命令就能在线复制一份一致性快照。本产品数据量小，凌晨低峰期用 SQLite 在线备份命令复制一份即可，用户完全无感知。只有极老的、不支持热备的数据库才需要停服窗口。

回滚时数据不兼容怎么办

最疼的回滚不是代码回滚，是数据库回滚。新版代码给 users 表加了一列 phone，跑了一天；现在要回滚到旧版，旧代码不认识 phone 这一列——这通常不致命（多一列旧代码不理会）。但反过来：新版把 phone 列删了、或者把「手机号」从一列拆成「国家码+号码」两列，回滚到旧版就直接崩。这就是前向/后向兼容问题。