旧版本 Discuz 7.2 升级到 X3.5 转换程序报错如何处理

Discuz 7.2 升级到 X3.5 转换程序报错通常是因为字符集不兼容或 PHP 版本环境差异，最推荐的处理方向是先备份数据，再检查转换脚本运行的 PHP 环境是否符合旧版本要求，最后按官方路径分阶段升级。

先说结论：Discuz 7.2 到 X3.5 跨度较大，直接转换容易因数据库结构差异和编码问题报错，建议优先验证中间版本过渡方案。

先确认：检查当前服务器 PHP 版本是否支持转换程序运行，确认数据库字符集是 GBK 还是 UTF8。
先处理：若报错涉及字符集，先在数据库层面统一编码；若报错涉及文件缺失，补充完整的转换程序包。
再验证：转换完成后登录后台检查数据完整性，确认无乱码且核心表结构正常。

快速处理思路

转换程序报错时不要直接刷新页面重试，应先查看错误日志定位具体类型。如果是数据库连接错误，检查 config.php 配置；如果是白屏或 Fatal Error，切换至 PHP 5.6 或 7.0 环境运行转换脚本；如果是数据截断，调整 MySQL 的 max_allowed_packet 参数。

# 检查 PHP 版本命令
php -v
# 查看 MySQL 最大包大小
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

为什么会这样

核心原因是 Discuz 7.2 与 X3.5 的数据库架构和编码标准存在代际差异。Discuz 7.2 默认使用 GBK 编码且基于旧版 MySQL 结构，而 Discuz X3.5 强制要求 UTF8 编码且表结构大幅调整，转换程序需要在运行过程中完成编码转译和表重建，任何环境不匹配都会导致中断。

分步处理

按以下顺序操作可降低报错概率，每步完成后需确认状态再进入下一步。

第一步：全量备份
使用 phpMyAdmin 或 mysqldump 导出完整数据库，备份 forum 目录所有文件。验证方法是尝试在本地导入备份文件，确保备份可用。

第二步：环境准备
将转换程序上传至网站根目录，确保转换脚本所在目录有写入权限。若服务器 PHP 版本高于 7.0，建议临时降级或使用 Docker 容器模拟 PHP 5.6 环境运行转换脚本，避免函数废弃报错。

第三步：执行转换
访问转换程序 URL，按向导操作。若中途报错，记录错误信息。常见操作是修改 source/include/function/function_core.php 中涉及编码转换的部分，或手动执行报错提示的 SQL 语句。

第四步：清理缓存
转换完成后，删除 data/template 和 data/cache 目录下的所有文件。验证方法是重新访问前台，确认模板渲染正常。

怎么验证是否生效

通过前台发帖、后台登录和数据对比三项指标验证。前台尝试发布含特殊字符的帖子，确认无乱码；后台登录用户中心，确认用户积分和等级数据保留；对比旧站与新站的帖子总数，误差应在合理范围内。

# 检查数据库表前缀是否一致
mysql -e "SHOW TABLES LIKE 'pre_common_setting';"

常见坑

直接覆盖文件而不运行转换程序会导致数据库结构不匹配报错。跳过中间版本直接跨大版本升级容易丢失自定义字段数据。转换过程中服务器超时会导致数据不一致，需调整 PHP max_execution_time 参数。

常见问题

转换程序运行白屏怎么办

通常是 PHP 版本过高导致旧函数不可用，建议切换至 PHP 5.6 环境重新运行转换脚本。

升级后论坛内容显示乱码

这是字符集转换不彻底，需在数据库中将所有表 Collate 统一修改为 utf8_general_ci 并刷新缓存。

可以直接从 7.2 升到 X3.5 吗

官方建议通过中间版本过渡，直接升级风险较高，若必须直接升级需确保使用最新版的官方转换工具。

笙亿网络策划