升级前检查比升级后救火便宜得多。

\n
Docker 服务升级最怕“顺手”。看到有新镜像，点一下更新，容器重新创建，页面还能打开，就以为结束了。真正的风险往往在后面：数据库迁移不可逆，配置字段变了，权限要求变了，后台任务失败，移动端客户端不兼容。升级前做检查，比升级后抢修便宜得多。

先确认备份可恢复

升级前第一件事不是拉镜像，而是确认备份。配置目录、数据目录、数据库导出、compose 文件和 .env 都要在备份范围内。只看到备份任务成功还不够，至少要知道最近一次恢复演练是什么时候，恢复步骤在哪里，密码和目标是否可用。

对于数据库型服务，升级前最好单独导出一份逻辑备份。目录快照能提供回滚点，但跨版本数据库迁移失败时，逻辑备份更容易在测试环境验证。对于照片、文档、菜谱这类生活数据，升级前还要确认原始文件没有被排除在备份之外。

版本和变更说明要一起看

镜像标签要明确。核心服务尽量不要长期使用 latest 自动漂移，至少在升级窗口里记录旧版本和目标版本。看变更说明时重点关注几类内容：数据库迁移、配置文件格式变化、环境变量废弃、默认端口变化、权限要求变化、服务拆分、最低依赖版本。

如果跨多个大版本，不要默认可以一步到位。有些应用要求按版本顺序迁移，跳太远会失败。家用服务不需要追最快版本，稳定和可恢复更重要。看到重大变更时，可以先在测试目录用备份副本跑一遍，确认升级路径再动正式服务。

回滚不是一句话

真正的回滚要提前准备。仅仅保留旧镜像不够，如果新版本已经修改数据库或数据目录，旧镜像可能无法再读。回滚计划至少包括旧镜像标签、升级前配置、数据快照、数据库备份和恢复步骤。升级前把这些放在同一处，出问题时才不会手忙脚乱。

我会避免升级后立刻清理旧镜像和旧备份。观察一段时间，确认常用功能、定时任务、客户端和日志都正常，再做清理。对于重要服务，观察窗口至少覆盖一次日常任务周期，比如一次夜间备份、一次自动扫描或一次家庭成员实际使用。

验证要覆盖真实功能

升级后页面能打开只是最低标准。每个服务都应该有自己的验证清单。文件服务要上传、下载、权限检查；照片服务要打开原图、搜索、后台任务；仓库服务要登录、clone、push；备份服务要跑一次小任务并恢复一个文件；监控服务要确认抓取和告警。

验证时要看日志。很多升级问题不会直接显示在页面上，而是后台反复报错。docker compose ps、最近日志、容器重启次数、健康检查状态都要看。发现异常先保留现场，不要连续升级或重复重建，把单一问题变成多重问题。

更新方式要可追溯

无论用命令行、面板还是自动更新工具，都要留下记录：升级时间、操作者、旧版本、新版本、变更摘要、备份位置、验证结果和遗留问题。HomeLab 不是企业机房，但也需要最小变更记录。否则两周后出现异常，很难判断是否和那次升级有关。

我更倾向把核心服务升级变成固定流程：读说明，确认备份，拉取镜像，停止服务，保留快照，启动新版本，执行验证，观察日志，更新维护记录。低风险服务可以简化，但数据库、照片、仓库、备份、密码管理这类服务不要省步骤。

什么时候不升级

不是所有新版本都值得马上升级。当前版本稳定、变更说明涉及重大迁移、备份没有验证、近期没有维护时间、家人正在高频使用服务，这些情况下都可以推迟。安全修复当然要重视，但也要在可恢复的前提下做。升级的目标是让服务更可靠，不是让版本号更好看。

把备份、版本、变更说明、回滚和验证连成一条链，Docker 服务升级就会从“碰运气”变成可管理的维护动作。只要这条链不断，即使升级失败，也能把影响控制在可接受范围内。

升级窗口也要选对。不要在需要马上使用服务前升级，也不要在自己没有时间观察日志时升级。家庭服务虽然规模小，但影响的是日常生活。比较稳的时间是有完整空档、能接受短暂停机、备份刚验证过的时候。升级后至少留出一段观察时间，确认常用入口没有隐藏问题。

自动更新工具适合低风险服务，不适合所有服务。入口页、临时工具、无状态小应用可以自动化；数据库、照片、仓库、备份、密码类服务更适合手动升级。自动化不是目标，可靠才是目标。能自动更新的服务，也要有失败通知和回滚记录。

升级后的记录要及时补。不要等几天后凭印象写，因为那时已经忘了具体版本和异常日志。记录里保留旧版本、新版本、备份时间、验证项目和观察结论。下次升级前翻一眼，就知道上次哪里顺利、哪里需要特别小心。

如果升级后出现小异常，也要记录是否已确认无害。没有结论的问题不要悄悄跳过，它很可能在下一次升级时放大。