旧版cms无法自动更新是因程序停更、官方源失效或php/mysql版本不兼容；无损升级核心是先验证再操作，需查迁移脚本、php配置及.user.ini限制，并优先使用宝塔应用中心升级。
旧版 CMS（如帝国CMS 7.5、WordPress 5.2、Typecho 1.1）卡在宝塔面板里无法自动更新，不是面板问题，而是程序自身已停止维护、官方源失效或依赖的 PHP/MySQL 版本被新版环境弃用。直接覆盖升级有极高风险：数据库结构不兼容、插件冲突、前台白屏、后台登录失败。所谓“无损”，核心是「先验证再操作」，不是跳过备份硬上。
确认 CMS 是否真能无损升级
别信“最新版安装包放上去就完事”。先查三件事：
- 去该 CMS 官网或 GitHub 仓库看
CHANGELOG.md或发布页，确认你当前版本到目标版本之间是否存在数据库迁移脚本（如 WordPress 的wp-admin/upgrade.php、帝国CMS 的/e/update/目录） - 查目标版本最低 PHP 要求，进宝塔「软件商店」→ 对应 PHP 版本 → 「设置」→ 「配置修改」，确认
php.ini中max_execution_time≥ 300、memory_limit≥ 512M —— 旧版升级器常因超时中断 - 检查当前站点根目录下是否有
.user.ini文件，里面若含open_basedir或硬编码的php_version=72，必须删掉或改匹配新 PHP 版本号，否则升级页面直接 500
用宝塔应用中心升级（仅限有官方支持的 CMS）
WordPress、Discuz! X3.5+、Typecho 1.2+ 等在宝塔「应用中心」里有托管包，走的是封装好的升级流，比手动安全。但注意：
- 点「应用中心」→ 搜索 CMS 名 → 找到已安装项 → 右侧「更多」→ 「升级」，它只会更新核心文件，不会动你改过的主题、插件、
wp-config.php或e/config/config.php - 升级前，应用中心会自动备份当前版本到
/www/backup/site/你的域名_时间戳.zip，但不包含数据库——你得自己进 phpMyAdmin 导出 SQL - 若升级后首页空白，立刻去
/www/wwwlogs/你的域名.error.log查最后一行，常见报错如PHP Fatal error: Uncaught Error: Class 'mysqli' not found，说明新 PHP 版本没开mysqli扩展，回「软件商店」→ PHP 设置 → 「安装扩展」勾上即可
手动覆盖升级时必须做的三步检查
官网下载完整安装包解压后，上传覆盖前停掉所有可能写库的操作（关评论、暂停订单、禁用缓存插件），然后：
- 删掉旧程序里的
install/、e/install/或wp-admin/install.php这类安装入口，防止被恶意访问重装 - 对比新旧
config.php或wp-config.php，把数据库连接信息、密钥、自定义常量（如WP_DEBUG）手工复制过去，不要直接覆盖整个配置文件 - 上传完别急着访问，SSH 进服务器执行：
chown -R www:www /www/wwwroot/你的域名和find /www/wwwroot/你的域名 -type f -exec chmod 644 {} \;，避免因权限错导致升级脚本无写入权限
升级后必验的两个关键点
很多问题不是升级失败，而是没走到验证环节就以为完事了：
- 进数据库，查
wp_options（WordPress）或phome_enewsclass（帝国CMS）表，确认db_version或类似字段值是否已更新为目标版本号——这是最硬的升级成功证据 - 用宝塔「计划任务」新建一条 Shell 脚本：
curl -I http://你的域名/wp-admin/upgrade.php 2>/dev/null | head -1，设为每分钟执行一次，等返回HTTP/1.1 200 OK再停掉，确保升级流程真跑完了，不是卡在中间
最易被忽略的是：旧 CMS 升级后，其自带的「数据备份」功能可能仍指向老路径或调用废弃函数，建议升级完成后立即用宝塔「数据库」→ 「导出」做一次全量 SQL 备份，而不是依赖程序内建备份。
