发布版本停用：如何安全管理软件迭代中的旧版本

发布版本停用的常见场景

在日常开发和运维中，新版本上线后，旧版本往往需要逐步退出服务。比如某次更新修复了支付漏洞，老版本存在安全风险，就必须尽快停用。这时候“发布版本停用”就成了一项关键操作。

常见的触发场景包括功能重构、安全补丁、兼容性调整，甚至是用户使用习惯的变化。例如，某个App的v1.5版本使用的是过时的登录接口，服务器端决定下线该接口，那么所有低于v2.0的版本都会被强制停用。

停用前的准备工作

直接切断旧版本访问并不稳妥。更合理的做法是提前通知，预留缓冲期。可以通过应用内弹窗、推送消息或后台标记的方式提醒用户升级。

同时，在配置系统中设置版本白名单是一种常用手段。服务器根据客户端上报的版本号判断是否允许继续使用。这种方式灵活可控，适合灰度停用。

{
  "allowed_versions": ["2.1.0", "2.1.1", "2.2.0"],
  "blocked_message": "当前版本已停用，请升级到最新版继续使用。"
}

通过配置实现动态控制

将版本控制逻辑放在配置中心，可以做到不停机调整。比如使用Nacos或Apollo管理版本策略，一旦发现紧急问题，运维人员可以立即屏蔽某个旧版本，无需重新发布服务。

实际配置中，除了黑名单，还可以设置降级提示。例如，v1.8用户还能短暂使用基础功能，但无法进入新增模块，并持续提示升级。

这种策略对老年用户或网络较差地区的使用者更友好，避免一刀切带来的投诉激增。

自动化脚本辅助清理

当确认某个版本长期无访问量后，可以启动清理流程。数据库中归档该版本相关日志，CDN下架对应安装包，镜像仓库打标为deprecated。

以下是一个简单的检查脚本示例，用于统计各版本最近7天的活跃数：

#!/bin/bash
for version in $(cat version_list.txt); do
  count=$(grep "version=$version" access.log | wc -l)
  echo "$version: $count times"
done

根据输出结果，长时间零访问的版本就可以列入正式下线名单。

与CI/CD流程集成

现代软件交付流程中，版本停用也应纳入自动化体系。可以在Jenkins或GitLab CI中添加“版本生命周期管理”任务，新版本稳定上线一周后，自动触发对指定旧版本的停用指令。

这类任务通常调用内部API完成，例如：

curl -X POST https://api.config.duomai.com/v1/version/disable \
  -H "Authorization: Bearer ${TOKEN}" \
  -d '{"version":"1.8.0","reason":"security_update"}'

执行后，配置中心同步更新，全网生效。