★ FEATURED ARTICLE 简介该压缩包整合了Discuz! 7.2论坛、UCenter 1.5和UCenter Home 2.0三大程序的GBK编码版本面向需要搭建或维护老式中文社区的技术人员尤其适合在GBK环境下处理中文内容、调试插件或进行历史项目二次开发。包内共2000个文件以PHP功能模块和HTM模板页面为主辅以GIF/JPG/PNG图片素材、CSS样式、JS脚本、XML配置、SQL数据表及少量音频与SWF动画整体仅7MB便于下载部署压缩包根目录的readme.txt说明了安装与配置要点upload目录对应上传文件存放区。借助SQL文件可以快速还原论坛数据配合PHP源码和模板可深入调整站点逻辑、界面样式与编码转换细节非常适合用于本地调试、站点迁移或对照学习经典Discuz!架构。目前已有114人浏览学习对研究老式中文论坛程序或GBK字符集处理的开发者而言这套文件是一份可运行的实践样本也适合作为备份参考。1. 这个 ZIP 是什么三件套老代码还在守着老站的数据看到UC1.5_UCH2.0_DZ7.2_SC_GBK.zip有年头的老运维一眼就明白这是 UCenter 1.5、UCHome 2.0、Discuz 7.2 三套系统的历史集成包SC 指简体中文GBK 代表源码和数据库统一使用 GBK 编码。这套组合在 2009 年前后是中小社区常见的建站搭配Discuz 做论坛主程序UCHome 提供个人动态和日志空间UCenter 架在中间做统一登录与用户数据同步。如今它仍躺在大批老服务器的 web 目录里不是不想升级而是历史数据、第三方插件和模板被 GBK 编码和旧版 API 绑死动一次牵一发动全身。这篇笔记写给接手这类老站的运维和想做本地复现的开发者环境怎么选、三套系统怎么装怎么配、GBK 迁移的坑在哪、典型故障怎么排查全程给可直接照抄的命令和参数。2. 解压前先读包结构目录角色、版本搭配与 GBK 编码约束拿到安装包后的第一个动作不应该是双击解压而是先把文件名的版本信息和包内目录结构拆开看一遍。这套旧架构的目录不是随便堆的三个应用对应三块代码目录之间的配置联动直接决定安装顺序。这一章先讲清结构和分工再解释 GBK 编码为什么是贯穿始终的硬约束最后给两条实际操作中马上用得上的验证命令。2.1 文件名拆解与三套系统的分工先读文件名本身。UC1.5是 UCenter 1.5UCH2.0是 UCHome 2.0DZ7.2是 Discuz 7.2SC是简体中文语言包GBK是整套源码和存储数据的编码。这几个信息组合在一起说明你拿到的不是单纯一个论坛程序而是一个“用户中心 社交主页 论坛”的组合方案三者之间通过 UCenter 建立用户数据关联。缩写对应系统核心职责UC1.5UCenter 1.5统一用户中心维护全站注册账号、密码、各应用注册信息UCH2.0UCHome 2.0个人空间应用提供动态、日志、相册、好友关系DZ7.2Discuz 7.2论坛主程序负责版块、帖子、权限、积分SCSimplified Chinese简体中文界面与语言文件GBK字符编码源码文件、数据库表、HTTP 输出统一使用 GBK三个系统之间的依赖顺序是明确的Discuz 和 UCHome 都是 UCenter 的“应用”两者的用户表不直接存密码而是由 UCenter 统一认证。用户在论坛登录时Discuz 把密码交给 UCenter 校验校验通过后 UCenter 再通知各应用写入登录状态。这套设计的直接后果是UCenter 挂了论坛和空间都无法完成登录但浏览帖子通常不受影响。理解这一点后面处理通信失败问题就有了排查方向。解压后用tree验证目录布局unzip UC1.5_UCH2.0_DZ7.2_SC_GBK.zip -d legacy_bbs tree -L 2 legacy_bbs正常输出里应该有 UCenter 目录常见名为ucenter、UCHome 目录home、Discuz 主目录upload并且包含install安装目录。如果解压后看不到install这个包大概率是别人的整站备份而非安装包处理方式完全不同备份包要配合原站数据库恢复安装包则用向导重新初始化。这个判断在接手二手包时特别重要能避免浪费大量时间。典型包的目录映射legacy_bbs/ ├── upload/ # Discuz 7.2 主程序 │ ├── config.inc.php # 论坛数据库配置与 UC 应用配置 │ ├── install/ # 安装脚本与 install.sql │ ├── admincp/ # 论坛管理后台 │ ├── data/ # 附件、缓存、备份目录 │ └── include/ # 公共函数库与数据库操作类 ├── ucenter/ # UCenter 1.5 用户中心 │ ├── config.inc.php │ ├── data/ │ └── api/ └── home/ # UCHome 2.0 个人空间 ├── config.php └── data/实际包的结构可能有差异但核心职责不变。安装前先认清楚哪个目录对应哪个系统再按顺序装能省掉后面大量配置回填工作。2.2 三处编码必须一致源码、数据库、HTTP 输出GBK 版与 UTF-8 版的本质区别不在代码逻辑而在字节流的解释方式。GBK 是中文字符的双字节编码URL 编码、表单提交、数据库连接参数、文件读写的每一环都在传递字节流任何一环按 UTF-8 去解释汉字就显示为乱码。乱码的三类表现需要能快速区分现象可能的错位页面出现“锟斤拷”“烫烫烫”浏览器按错误字符集解码了字节流中文变成???问号数据库字段字符集不支持某些汉字写入时被替换登录后用户名乱码但帖子正常cookie 或会话数据编码与页面编码不一致排查第一步是看源码文件编码。用file检查几个关键文件file upload/include/db_mysql.class.php ucenter/config.inc.php home/config.php如果输出为ISO-8859或Non-ISO extended-ASCII说明文件是 GBK。为什么file不直接显示GBK因为 GBK 不是标准编码类别file无法识别为 UTF-8 时会落入这个分类。如果输出里出现UTF-8 Unicode说明文件被转码过与包内其他文件不一致乱码只是时间问题。确认文件编码后还要核对数据库连接的字符集。安装完成后三个配置文件里各有一个字符集定义逐一检查grep -rn CHARSET\|charset upload/config.inc.php ucenter/config.inc.php home/config.php 2/dev/null输出里只要出现utf8或utf-8就要改回gbk。这里有个高发的细节数据库连接字符集与页面输出字符集是两回事有些文件里有两个不同配置项一个控制数据库SET NAMES一个控制 HTML 的Content-Type。只改其中一个页面编码正常但数据库读写乱码或者反过来。GBK 包里常见的是这种结构$dbcharset gbk; // 数据库连接字符集 header(Content-Type: text/html; charsetgbk); // 页面输出字符集$dbcharset会拼进数据库连接初始化语句等价于每次连接后执行SET NAMES gbk。这个值被改成utf8后从 MySQL 取出的数据按 UTF-8 转换再按 GBK 页面编码输出字形必然对不上。验证 MySQL 侧的真实状态SHOW VARIABLES LIKE character_set_database; SHOW VARIABLES LIKE collation_database;如果character_set_database不是gbk需要从建库语句上修正。这个查询不产生变更任何时间执行都安全。我习惯在导入 SQL 前先跑一次避免坏数据入库。2.3 安装 SQL 文件的编码检查与导入前锁定安装包自带一个初始 SQL 文件它决定整个数据库的最初结构与默认数据。GBK 包对应的 SQL 文件自然是 GBK 编码但这类老包经历过很多次转手拷贝被编辑器转成 UTF-8 的情况时有发生。导入前检查成本最低导入后发现问题再清理就是灾难。file upload/install/install.sql预期同样落在ISO-8859或Non-ISO extended-ASCII。如果显示UTF-8 Unicode说明文件已经被转码。这时先在本地转回 GBK而不要直接修改包内原文件iconv -f UTF-8 -t GBK upload/install/install.sql install_gbk.sqliconv有一个隐患如果原文件已因多次转码产生“锟斤拷”这类不可逆字符iconv会报错或输出替换字符。所以转码前先确认内容可读性head -20 upload/install/install.sql前 20 行的 SQL 注释区域会包含建表说明等中文。如果这里已经乱码说明文件损坏发生在打包之前需要另找源包而不是反复转码。转码只能修复编码标记错误不能恢复丢失的字节。导入时使用 mysql 客户端的--default-character-setgbk参数。漏掉它的典型表现是导入过程不报错但表里中文全是乱码因为客户端按系统默认字符集解释 SQL 文件字节流再转换成目标表的 gbk 编码等于从入口就把数据带歪。完整的初始化命令mysql -uroot -p --default-character-setgbk -e CREATE DATABASE IF NOT EXISTS \dz_bbs\ DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci; mysql -uroot -p --default-character-setgbk dz_bbs upload/install/install.sql mysql -uroot -p --default-character-setgbk -e SHOW TABLES FROM dz_bbs;COLLATE gbk_chinese_ci是 GBK 简体中文的默认校对规则按拼音排序中文用户名与老程序里ORDER BY username的行为一致。如果改成gbk_bin排序变成二进制比较用户列表顺序会异于预期。这里不要因为“追求新版”把校对规则改成utf8mb4后面程序会难以适配。3. 搭建最小可运行环境PHP 版本选型与数据库初始化老代码跑起来的第一道门槛是运行环境。现在的 PHP 已经到 8.x但这个包里的代码写于 PHP 5.2/5.3 时代数据库操作层大量使用早已移除的函数。这一章把版本选型逻辑讲透再完整给出数据库初始化和安装顺序让新手能照着操作、熟手能快速对照参数。3.1 PHP 版本取舍5.2/5.3 是最稳原生环境新版必须打兼容层选 PHP 版本之前先明确老代码对版本敏感的位置。核心问题集中在三个点mysql_*函数族在 PHP 7.0 被移除、ereg/split等正则函数在 PHP 7.0 消失、session_register在 PHP 5.4 已废弃。下表汇总了处理这个包时最高频遇到的老函数及其去向函数作用替代方案mysql_connect/mysql_query/mysql_fetch_array数据库连接与查询mysqli_*或PDOereg/ereg_replacePOSIX 正则匹配与替换preg_match/preg_replacesplit按模式分割字符串explode/preg_splitsession_register/session_unregister注册会话变量$_SESSION直接赋值mysql_escape_string字符串转义mysqli_real_escape_string两条路线供选择。路线一是直接搭 PHP 5.2/5.3 环境优点是代码零修改缺点是软件源难找。实际操作中常用老版本 Linux 发行版或第三方 Docker 镜像来跑比如某开发者在模拟项目X里用的是 CentOS 6 配合 PHP 5.3整个包解压即用没有遇到任何函数缺失问题。路线二是在现代 PHP 上运行给代码加兼容层优点是环境好找缺点是需要逐个补函数。兼容层的常见做法是在入口文件前引入一个补丁文件把缺失的mysql_*函数重新映射到mysqli?php // compat.php为 PHP 7 环境提供 mysql_* 函数兼容 if (!function_exists(mysql_connect)) { function mysql_connect($host, $user, $pass) { $conn mysqli_connect($host, $user, $pass); return $conn ? $conn : false; } } if (!function_exists(mysql_query)) { function mysql_query($sql, $conn null) { static $default_conn null; if ($conn null) { if ($default_conn null) { $default_conn mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD); } $conn $default_conn; } return mysqli_query($conn, $sql); } } if (!function_exists(mysql_fetch_array)) { function mysql_fetch_array($result) { return mysqli_fetch_array($result); } } if (!function_exists(mysql_num_rows)) { function mysql_num_rows($result) { return mysqli_num_rows($result); } } if (!function_exists(mysql_insert_id)) { function mysql_insert_id($conn null) { return mysqli_insert_id($conn); } }这段代码的意图是让老代码里的mysql_*调用落到mysqli实现上。注意几个细节mysql_connect的第 4 个参数是布尔值而非端口如果你的补丁需要同时兼容老代码里的逐位参数传递还要处理参数个数不一致的问题。mysql_query的第二个参数在老写法里可能省略所以补丁里用了一个静态变量保存默认连接。这些细节是兼容层最容易出错的地方某个函数没补全或参数顺序不同仍然会白屏。我的判断是兼容层适合临时过渡或本地调试生产环境最好还原到老版本 PHP不要在兼容层上赌稳定性。无论走哪条路线装好后用phpinfo()探针验证环境都是第一步?php phpinfo();放到站点根目录后浏览器访问确认PHP Version、mysqli扩展是否启用、Configure Command里是否包含--with-mysql。新版 PHP 环境如果连mysqli都没装后面任何操作都无从谈起。3.2 MySQL 5.5/5.7 环境下的建库、导库与校验GBK 版本的数据库初始化不只是执行一条 SQL它需要把建库字符集、导入字符集、客户端字符集三个环节锁成一致。这套包年代对应的 MySQL 是 5.1/5.5实际开发中在 MySQL 5.7 上跑通是常见做法MySQL 8.0 则需要额外处理sql_mode和不支持的语法。建库语句必须显式指定字符集与校对规则CREATE DATABASE IF NOT EXISTS dz_bbs DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;IF NOT EXISTS是为了重复执行时不报错。库名dz_bbs可以换成你喜欢的名字但后续所有配置文件里的库名要同步修改不要只改一处。接着导入初始 SQLmysql -uroot -p --default-character-setgbk dz_bbs upload/install/install.sql导入过程如果遇到如下报错处理方式各不同报错原因与处理ERROR 1064SQL 语法不被当前 MySQL 支持通常是老写法TYPEMyISAM需替换为ENGINEMyISAMERROR 1115字符集设置冲突确认 SQL 文件内没有混入utf8声明ERROR 1366字符集不符个别中文无法写入进一步落实连接参数TYPEMyISAM是 MySQL 4.x 时代的表类型写法5.7 以上版本不再识别导入前全局替换掉cp install/install.sql install.sql.bak sed -i s/TYPEMyISAM/ENGINEMyISAM/g install/install.sqlsed -i直接改原文件所以先备份是养成习惯的问题。MySQL 8.0 环境里导入老 SQL 还可能遇到ONLY_FULL_GROUP_BY报错这是sql_mode默认值变化导致的。用会话级参数临时放宽mysql -uroot -p --default-character-setgbk --sql_modeSTRICT_TRANS_TABLES dz_bbs install/install.sql这个参数只作用于当前连接不动 MySQL 全局配置导入完成后自动失效适合一次性导入场景。导入后校验是很多人跳过的步骤建议至少花一分钟执行一次mysql -uroot -p --default-character-setgbk -e SHOW TABLES FROM dz_bbs; | head -30 mysql -uroot -p --default-character-setgbk -e SELECT uid,username FROM dz_bbs.cdb_members LIMIT 5;第一条确认表前缀和表数量。Discuz 7.2 默认前缀是cdb_如果看到pre_说明 SQL 文件来自其他版本系列和当前程序对不上要立即停下找正确的 SQL。第二条抽查中文用户数据输出正常说明编码链路已经打通。这里有一个高频误判用终端直接查询时终端默认 UTF-8GBK 数据被终端按 UTF-8 解码看起来乱码但数据库里其实是好的。判断方法就是在第二条命令里加上--default-character-setgbk加了之后仍然乱码才说明数据真坏了。3.3 三套系统的安装顺序与配置联动参数数据库就绪后进入安装环节。基于 UCenter 作为统一认证中心的架构安装顺序正确与否直接影响后续联动。正确顺序是先装 UCenter再装 Discuz最后装 UCHome。原因在于 Discuz 和 UCHome 的安装向导需要向 UCenter 注册应用并拿回应用 ID 和通信密钥。反过来装虽然能完成但 UCenter 里的应用列表为空要手动补注册很容易漏参数。UCenter 装好后先记录后台的“应用管理”里生成的密钥和接口地址。Discuz 安装时填入这些信息安装完成后在upload/config.inc.php里检查几项关键参数define(UC_CONNECT, mysql); define(UC_API, http://127.0.0.1/ucenter); define(UC_KEY, a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6); define(UC_APPID, 1); define(UC_DBCHARSET, gbk);参数含义分别是UC_CONNECT为连接方式mysql表示直接读取 UCenter 数据库api表示走接口请求UC_API是 UCenter 的可访问地址服务器之间必须互通UC_KEY是通信密钥必须与 UCenter 后台里该应用的记录完全一致UC_APPID是应用 IDUC_DBCHARSET固定保持gbk。UCHome 的home/config.php里同样有一组参数结构类似UC_APPID通常是 2define(UC_CONNECT, mysql); define(UC_API, http://127.0.0.1/ucenter); define(UC_KEY, a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6); define(UC_APPID, 2); define(UC_DBCHARSET, gbk);三个系统同域部署时cookie 作用域需要收敛到一级域。例如站点域名为www.example.comUCenter 装在www.example.com/ucenterDiscuz 装在根目录cookie 域配置留空或设为.example.com。设成带端口的地址则会引发登录不同步一个应用登录了另一个应用仍是游客状态。安装完成后建议立刻做一次通信检测。Discuz 后台的 UCenter 设置里通常有通信检测按钮App 应用显示“通信成功”代表整条链路通畅。如果失败回到第 5 章的排查路径。4. 从旧服务器搬迁到新机文件迁移、数据库导出与配置修正接手老站最多的任务不是重新安装而是整体搬迁。搬迁比新装多一层难度源环境里 PHP 版本、MySQL 版本、字符集设置都要先摸清再对照目标环境补齐差异。这一章按操作顺序给出文件迁移、数据库备份恢复、配置修正的完整流程重点讲字符集锁定的操作细节。4.1 文件迁移tar 打包保留权限和软链比 zip 更适合 PHP 站点老站点目录里通常混着模板、附件、插件、缓存文件。用zip打包容易丢权限和符号链接解压后 PHP 报没有权限的错误。更合适的做法是用tar保留属主和权限位。打包命令示例tar czf legacy_bbs_backup.tar.gz \ --excludedata/cache \ --excludedata/templates \ -C /var/www legacy_bbs--exclude跳过编译型缓存目录可以显著减小体积这两个目录会在站点重新访问时自动生成。但如果原站因为运行异常已经无法正常生成缓存这条路就不能用了需要连缓存一起搬否则站点会白屏。上传到新服务器后解包mkdir -p /var/www/legacy_bbs tar xzf legacy_bbs_backup.tar.gz -C /var/www/legacy_bbs chown -R www-data:www-data /var/www/legacy_bbschown这步经常被忽略结果是页面能打开但附件下载失败、缓存写入失败。PHP-FPM 跑在哪个用户下目录属主就该是哪个用户。判断当前 web 服务用户可以用这条命令ps aux | grep php-fpm | head -3输出里第一列的属主就是 PHP 进程运行用户目录权限对齐到它。4.2 数据库备份与恢复mysqldump 必须锁定 GBK 字符集数据库导出这一步是老司机也会翻车的环节。最常见的是不带--default-character-setgbk的 mysqldump导出的备份文件在恢复后全乱。原因是 mysqldump 在导出过程中按连接默认字符集解释数据并做转换备份文件里已经不是纯正的 GBK 字节流。正确的导出命令mysqldump -uroot -p --default-character-setgbk \ --set-gtid-purgedOFF \ --single-transaction --routines --triggers \ dz_bbs dz_bbs_gbk.sql参数逐一解释--default-character-setgbk让连接按 GBK 解释字节流禁止导出过程中做字符集转换--single-transaction对 InnoDB 表获取一致性快照避免导出期间数据变化--routines --triggers保留存储过程和触发器老站点的积分插件或统计任务可能依赖它们--set-gtid-purgedOFF是 MySQL 5.7 以上导出时避免目标库收到 GTID 信息而拒绝导入。恢复侧命令与导出侧对齐mysql -uroot -p --default-character-setgbk dz_bbs dz_bbs_gbk.sql恢复之后立刻抽查含中文的数据确认无误再继续。示例mysql -uroot -p --default-character-setgbk -e SELECT uid,username,email FROM dz_bbs.cdb_members LIMIT 5;这里要特别提醒如果源库字符集曾经被改成utf8但数据仍是 GBK 字节上面这条命令导出时会因为字符集转换产生双重错误。判断源库真实状态的方法是在源服务器上执行SHOW CREATE TABLE cdb_members\G关注DEFAULT CHARSET的值如果和配置文件的$dbcharset不一致说明历史上有过字符集变更。这种库的备份要额外小心最好先在一个临时库导入后人工验证用户列表再切到生产。4.3 搬迁后的配置修正站点 URL、应用接口地址与通信密钥文件和数据库到位后站点首页能打开但帖子里的图片路径、附件下载地址很可能还指向旧服务器的域名或路径。三处需要修正Discuz 后台的“全局 → 站点信息 → 站点 URL”。config.inc.php里若有写死的绝对路径改为相对路径或使用常规定义。UCenter 后台的“应用管理”里各应用的接口 URL。通信密钥是最容易翻车的一项。如果备份文件里 UCenter 数据库和各应用的config.inc.php是同一时刻打出来的密钥一致无需改动。但很多站点的备份不是同一时刻打的应用配置是最新的UCenter 库里仍是旧密钥两边对不上登录功能直接失效。处理方式二选一一种是在 UCenter 后台重置该应用的通信密钥再把新密钥填回应用配置文件另一种是直接修改 UCenter 库里的应用表把密钥字段改成配置文件中的值。第二种对线上系统更稳不用经过后台界面触发更新示例UPDATE uc_applications SET appkey a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6 WHERE appid 1;执行前先 SELECT 确认当前值再 UPDATE改完后再到 Discuz 后台做一次 UC 通信检测。如果仍然失败按 5.2 节的路径排查。5. 常见问题与避坑乱码、通信失败、登录不同步排查路径这一章集中写我处理这类包时遇到频次最高的四类问题每条按“现象 → 原因 → 解决”三段式展开供遇到问题时直接对照。每一条都是真实环境里出现过、并且有明确解决方案的。5.1 页面乱码先分清是源码、数据库还是终端解码的问题现象安装完成后论坛帖子标题出现“锟斤拷”或者全部中文变成问号或者只有用户名乱码而帖子内容正常。原因三者之一源码文件被 UTF-8 编辑器改写过、数据库表字符集不是gbk、HTTP 响应头声明了utf-8。多数情况是前两种混合处理时要按顺序排查。解决按顺序检查三段。先看源码文件file upload/config.inc.php输出含UTF-8 Unicode说明文件被转码过用iconv转回iconv -f UTF-8 -t GBK upload/config.inc.php config.inc.php.gbk mv config.inc.php.gbk upload/config.inc.php再看数据库表定义mysql -uroot -p --default-character-setgbk -e SHOW CREATE TABLE dz_bbs.cdb_members\G | grep CHARSET输出utf8mb4时需要转回 GBKALTER TABLE cdb_members CONVERT TO CHARACTER SET gbk COLLATE gbk_chinese_ci;CONVERT TO CHARACTER SET会重新编码列中的数据。如果列里已经混入被错误转换过的数据必须先恢复备份再执行否则会越改越乱。最后检查 HTTP 响应头curl -I http://127.0.0.1/ | grep -i charset响应头里如果是charsetutf-8到配置文件里把页面输出字符集改回gbk也可以通过在程序入口处加一行header(Content-Type: text/html; charsetgbk);强制声明。5.2 UCenter 通信失败密钥和应用 ID 对不齐现象Discuz 后台显示“UCenter 通信失败”或用户登录后各应用之间状态不同步。原因最常见是UC_KEY不一致其次是UC_API地址在新环境里无法访问或者是应用 ID 对应错误。解决第一步验证网络连通性curl -v http://127.0.0.1/ucenter/api/uc.php 21 | head -20返回404说明路径不对需要检查config.inc.php里的UC_API是否指向正确的 UCenter 入口。返回500说明 PHP 环境有错查看 web 服务器错误日志定位。如果网络通进入 UCenter 后台的“应用管理”找到目标应用复制通信密钥回到应用配置里粘贴。粘贴时注意密钥前后不要有空格或换行这是最容易忽略的细节。确认UC_APPID也要对得上。UCenter 后台应用列表里每个应用都有独立 IDDiscuz 和 UCHome 的应用 ID 不能混用。如果填反了通信检测会报应用不存在。5.3 PHP 新版本下报错Call to undefined function mysql_connect()现象打开页面出现空白或直接提示未定义函数。原因PHP 7.0 起移除了所有mysql_*函数。现代的 PHP 8.x 环境如果没有兼容层老代码一调用就崩溃。解决两个方向。首选方向是换回 PHP 5.3 环境代码零修改。另一个方向是使用第 3.1 节的兼容层同时把调用点扫一遍grep -rn mysql_ --include*.php . | grep -v mysqli_ | head -30把残留的mysql_connect、mysql_query、mysql_fetch_array逐行改掉或纳入兼容层直到该命令没有输出。这个扫面过程会发现一些藏在插件和第三方模板里的调用这些地方最容易被遗漏。5.4 登录状态不同步cookie 作用域不一致现象在论坛登录成功跳到 UCHome 首页仍是未登录或反过来。本地开发环境一切正常部署到服务器后失效。原因各应用配置里的 cookie 作用域不一致。典型情况是 Discuz 的 cookie 域为空而 UCHome 的 cookie 域写成了带www的完整域名。浏览器在存储 cookie 时按域匹配导致两个应用互相看不到对方的登录态。解决把两处配置统一为同一作用域$_config[cookie][cookiedomain] .example.com;开头的点号代表匹配所有子域名。本地用 IP 调试时没有域名cookie 域保持为空cookie 只在当前路径下生效跨应用同步登录就会失效——这正是“本地正常、线上不行”的高频原因之一。6. 保留现场老系统的加固与应急备份习惯能走到这一章的读者基本已经让老站在新环境里跑起来了。最后说点别处很少提的延续性操作老代码怎么加固、怎么备份、怎么验证数据完整性。安全方面先做三件事。一是把管理后台入口从默认路径改掉。Discuz 7.2 的admincp目录是公开被扫描的路径把它改名或加访问 IP 限制可以挡掉大部分自动化试探。二是给data/目录加禁止执行 PHP 的规则Apache 环境可在目录里放.htaccessphp_flag engine off FilesMatch \.php$ Require all denied /FilesMatch这会阻止上传目录里被植入 PHP 文件后直接执行。三是定期备份脚本里带日期、保留最近 7 份#!/bin/bash BACKUP_DIR/backup/legacy_bbs DAY$(date %Y%m%d) tar czf $BACKUP_DIR/files_$DAY.tar.gz -C /var/www legacy_bbs mysqldump -uroot -p --default-character-setgbk dz_bbs $BACKUP_DIR/db_$DAY.sql find $BACKUP_DIR -name *.tar.gz -mtime 7 -delete find $BACKUP_DIR -name *.sql -mtime 7 -delete脚本放到 cron 里每天执行一次。备份文件最好落到独立磁盘或另一台机器防止源站宕机时备份一起丢失。性能方面老代码的查询没有经过现代优化数据增长到几万帖后列表页会明显变慢。优先做两件事在后台打开主题列表缓存和帖子缓存确认 MySQL 的查询缓存还在工作。MySQL 5.7 及以前版本查询缓存默认开启到 8.0 已经移除热点查询需要改到程序层缓存。具体方案依赖业务形态这里不展开。每次迁移或备份恢复后我习惯执行两条最小验证语句SELECT COUNT(*) AS members FROM cdb_members; SELECT MAX(dateline) AS last_post FROM cdb_posts;两条结果和源库不一致说明备份不完整或漏了表立即回滚重来不要先上线再排查。我的习惯是每次动这类老站都留一份不动的原始备份作为“后悔药”宁可磁盘多占几百 MB也不要在没有干净基线的情况下开始调。改配置前先cp改完跑通通信测试再删除旧文件。这套习惯帮我挡过很多次改坏密钥、改坏字符集的低级事故也希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
