宝塔面板迁移后网页乱码的核心是数据库字符集不一致，需先确认实际编码再安全转换存量数据，涉及导出参数、MySQL服务配置、程序配置及HTML声明等多层对齐。
宝塔面板迁移后网页显示乱码，先看数据库实际字符集
乱码不是“改个设置就能好”的问题，核心在于迁移前后数据库的字符集不一致。很多用户直接在 phpMyAdmin 里点“修改表结构”改 CHARSET=utf8mb4，但表里已有数据仍是旧编码（比如 latin1 或 utf8），表面看起来改了，实际读出来还是错的。
必须分两步：确认当前真实编码 + 安全转换存量数据。
- 登录宝塔 → 数据库 → 点击对应库名 → 执行 SQL：
SHOW CREATE DATABASE `your_db_name`;，看输出里的DEFAULT CHARSET=... - 再查一张典型表：
SHOW CREATE TABLE `wp_posts`;，注意DEFAULT CHARSET和每个TEXT/VARCHAR字段后的COLLATE - 如果库是
utf8但字段是latin1_swedish_ci，说明导入时没带编码声明，数据已损坏，不能只改表结构
mysqldump 导出时漏掉 --default-character-set 是常见根源
用宝塔“备份”功能导出的 SQL 文件默认不指定字符集，MySQL 会按服务端默认值（常为 latin1）解析文本，导致中文被错误转义。即使源站看着正常，导出文件本身已是乱码。
正确做法是在命令行手动导出（宝塔终端可用）：
mysqldump -u root -p --default-character-set=utf8mb4 --skip-set-charset --add-drop-table your_db_name > backup.sql
-
--default-character-set=utf8mb4告诉 mysqldump 按 utf8mb4 读取数据 -
--skip-set-charset防止 dump 文件里写死SET NAMES latin1这类冲突语句 -
--add-drop-table确保恢复时先删旧表，避免字段编码残留 - 别用宝塔图形化“下载备份”，它不支持传参，导出不可靠
导入 SQL 后仍乱码？检查 MySQL 服务端配置是否生效
就算 dump 文件正确，如果目标服务器的 MySQL 没启用 utf8mb4 支持，导入时会静默降级。重点检查三处：
- 宝塔 → 软件商店 → MySQL 设置 → 配置修改 → 确认
[mysqld]段有：character-set-server = utf8mb4collation-server = utf8mb4_unicode_ci - 重启 MySQL（不是重载）才能生效，宝塔界面点“重启”或终端执行：
systemctl restart mysqld - 连接后验证：
SHOW VARIABLES LIKE 'character_set%';，所有client/server/conneciton行都应是utf8mb4，只要有一项是utf8或latin1，PHP 读出来必乱
WordPress 等程序还要同步改配置和字段 collation
数据库层面改完，程序本身可能还卡在旧编码逻辑里。以 WordPress 为例：
- 检查
wp-config.php是否含：define('DB_CHARSET', 'utf8mb4');和define('DB_COLLATE', 'utf8mb4_unicode_ci'); - 运行 WP-CLI（宝塔终端）强制修复表：
wp db convert charset utf8mb4 wp_posts（逐表执行，别用wp db convert charset utf8mb4全局跑，容易崩） - 某些插件自建表可能漏改，进 phpMyAdmin 手动执行：
ALTER TABLE `wp_yoast_seo_links` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 浏览器访问时按
Ctrl+U查看源码，确认<meta charset="UTF-8">存在且位置在<head>最前面
字符集转换不是开关式操作，每层（服务端、连接层、表结构、字段内容、程序配置、HTML 声明）都要对齐，漏一层就白忙。最麻烦的是已损坏的数据——比如用 latin1 存过一次中文，再怎么改 charset 都救不回来，只能从原始未乱码环境重新导出。
