升级流程

升级是常规操作——但每次升级都有风险。本节给安全可靠的升级流程。

后台入口：系统 → 备份与升级

待补充截图 顶部当前版本 + 可用新版本提示 + 「立即升级」按钮 + 升级历史日志

系统升级面板

三类升级

1. BangNiCMS 系统升级

升级谁：BangNiCMS 系统本身（包括后台 + 前台 + 数据库 schema）。

频率：每月-每季度。

操作者：运维。

2. 主题升级

升级谁：第三方主题。

频率：取决于开发者发版。

操作者：运营（管理员）。

详见安装与切换主题。

3. 插件 / 模型包升级

升级谁：第三方插件 / 模型包。

频率：取决于开发者。

操作者：运营。

详见：

系统升级前检查

看 changelog / release notes
- 新功能
- 已知问题
- 是否需要数据迁移
- 是否有破坏性变更
完整数据库备份（必做）
测试环境演练（强烈推荐）：
- 把生产数据库恢复到测试环境
- 在测试环境跑升级
- 验证：内容、翻译、用户、扩展、前台都正常
通知用户：升级期间会有 5-30 分钟服务中断
选择低峰时段：晚上 / 周末
运维 + 关键业务方在线：万一出问题立刻处理

系统升级流程

典型升级（运维操作）：

进入维护模式：前台显示”维护中，预计 30 分钟恢复”
完整数据库备份
拉取新版本代码（git pull 或 Docker pull 新镜像）

数据库 schema 迁移（自动）：

迁移开始...
✓ 升级 SiteConfig 表（+1 字段）
✓ 升级 Inquiry 表（+2 索引）
✗ 失败：无法迁移 Article.tags 字段
  原因：现有数据 17 条不符合新 schema

重启服务
健康检查：
- API 响应正常
- 数据库连接正常
- 前台页面渲染正常
- 后台登录正常
退出维护模式：前台恢复访问
抽样测试：
- 任一产品的编辑页
- 任一文章的渲染
- 提交一条测试询盘
- 用户登录
关注监控 24-48h：
- 错误率
- 性能
- 用户反馈

升级时机

好的时机：

✅ 业务低峰（晚上 / 周末）
✅ 运维 + 业务方在线
✅ 已有 24h 内备份
✅ 已在测试环境验证
✅ 没有正在进行的促销活动

坏的时机：

❌ 大促进行中
❌ 节假日无人值守
❌ 关键演讲 / 会议前一天
❌ 投资人参观时

升级频率

建议：

升级类型	建议节奏
补丁版本（X.Y.Z）	每月评估，重要修复立刻升
次版本（X.Y.0）	每季度
主版本（X.0.0）	每年或观察 3-6 月再升

安全补丁例外：

严重漏洞 → 24-48h 内升级
高危漏洞 → 1 周内升级

主题 / 插件 / 模型包升级

详见各自章节：

多组件协作升级

如果同时要升级多个：

主题 v1 → v2
插件 A v1 → v2
模型包 X v1 → v2

顺序：

数据库优先：BangNiCMS 系统升级（如果需要）
模型包：因为字段变更影响内容
主题：因为可能引用模型包字段
插件：最后

每步独立验证再下一步。

升级期间的”维护模式”

后台支持维护模式：

前台显示”维护中”页（自定义文字）
后台登录仍可用（让运维操作）
自动跳转到客服 / 联系页

让运维在升级前开启维护，升级完成后关闭。

常见问题

升级失败有哪些症状？

后台进不去（500 错误）
前台白屏
API 返回错误
数据库连接失败
某些功能异常（如 AI 翻译失败）

升级期间用户会丢询盘吗？

不会——前台显示维护页时，用户看不到表单，不会提交。

但升级前已提交、升级中处理的少数请求可能失败。让运维升级前 5 分钟关闭表单（只读模式）。

我能”灰度升级”吗（先升级一半用户）？

当前不支持自动灰度 —— 需要复杂的运维方案：

部署两套 BangNiCMS（旧版 + 新版）
反向代理按 cookie / IP / 比例分流
监控数据 → 全部切换到新版

适合：极大型站点。中小站点直接全量升级 + 备份保险即可。

升级后旧主题还能用吗？

通常可以 —— 如果主题用的是稳定 API。

少数情况：BangNiCMS 主版本升级（X.0.0）可能有破坏性变更 → 主题需要适配。

让主题开发者确认兼容性再升级。

升级后用户需要重新登录吗？

通常不需要——BangNiCMS 用 token 认证，token 跨重启保留。

但少数情况（密钥轮换 / session 改架构）会强制重新登录。事先通知用户。

接下来

数据迁移 — schema 变更与回滚
升级前检查清单 — 自检
灾难恢复 — 升级失败的应急