本文约 2,955 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
迁移完成，你用自己的管理员账号好不容易登进了 WordPress 后台，本想改改设置，结果页面上弹出一句「您没有足够的权限访问此页面」（Sorry, you are not allowed to access this page），或者进「插件」「用户」等页面时被挡在门外。更离谱的是，有的站点登录后连仪表盘都显示不全，只剩几个菜单，明明是对着管理员账号，权限却像被降级成了订阅者。
这通常不是你的账号真被降权了，而是迁移过程中用户表或用户元数据（usermeta）出了问题：要么核心的 wp_usermeta 表没导入完整，要么权限字段里的表前缀还是旧的，导致 WordPress 找不到「你是管理员」这条记录。理清了这一点，修复起来就是补数据、改字段两件事。
故障原因分析
wp_usermeta表未完整导入。 用户权限记录存在这张表里，迁移时只导了wp_users而漏了usermeta，登录后权限自然为空。
capabilities字段里残留旧表前缀。 权限键名形如wp_capabilities，如果迁移后改了表前缀却只改了表名，这个字段名还是旧前缀，WordPress 就取不到角色。
user_level等元数据缺失。 老版本靠wp_user_level判断管理员等级，缺了它某些动作会被拒绝。
- 当前用户对应角色被清空。 迁移脚本处理序列化数据出错，
wp_capabilities的值变成空数组，等于没有任何权限。
- 多站点网络或插件权限覆盖。 若是 WordPress 多站点（Multisite），超级管理员记录在
wp_sitemeta，迁移漏了它同样会提示无权限。
分步解决方案
第一步：确认自己账号的 ID
在 phpMyAdmin 里查用户表，找到你的管理员用户名和它的 ID：
-- 换成你自己的表前缀和用户名
SELECT ID, user_login, user_email FROM wp_users WHERE user_login = '你的用户名';假设查出来 ID 是 1。
第二步：核对并修复 usermeta 权限字段
查看该用户的权限记录：
SELECT meta_key, meta_value FROM wp_usermeta WHERE user_id = 1;正常应该能看到 wp_capabilities，值是 a:1:{s:13:"administrator";b:1;}。如果：
- 完全没有这条记录：手动补上：
INSERT INTO wp_usermeta (user_id, meta_key, meta_value)
VALUES (1, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');- 键名带了旧前缀（如
oldsite_capabilities）：批量把前缀改掉：
UPDATE wp_usermeta
SET meta_key = REPLACE(meta_key, 'oldsite_', 'wp_')
WHERE meta_key LIKE 'oldsite_%';注意：meta_value 里角色名不受前缀影响，administrator 保持原样即可。
第三步：补回用户等级字段（老站点需要）
如果后台仍挡你，补一条 wp_user_level：
INSERT INTO wp_usermeta (user_id, meta_key, meta_value)
VALUES (1, 'wp_user_level', '10');管理员等级值为 10。
第四步：多站点场景补超级管理员
若是 Multisite，执行：
-- 把新管理员 ID 加入超级管理员列表
UPDATE wp_sitemeta SET meta_value = 'a:1:{i:0;i:1;}'
WHERE meta_key = 'site_admins';若原本已有超级管理员，需合并数组，别直接覆盖，否则会把其他人踢出去。
第五步：无 SQL 权限时用插件或函数恢复
如果你不熟悉数据库，可以在 wp-content 目录临时放一个自定义脚本，或使用 SFTP 修改后执行，通过 WordPress 函数给自己赋权：
<?php
// 文件路径：网站根目录/wp-content/temp-fix-role.php
// 用完务必立即删除，避免留下安全隐患
require_once dirname(__FILE__) . '/../wp-load.php';
$user = get_user_by('login', '你的用户名');
if ($user) {
$user->set_role('administrator');
echo '角色已设置为管理员，请删除本文件';
}访问 https://newdomain.com/wp-content/temp-fix-role.php 执行一次，看到提示后立刻删除该文件。
常见踩坑点
- 只改表名不改 usermeta 键名。 换成新前缀后，
capabilities字段里遗留旧前缀是「改前缀后丢权限」的高发原因，必须一起替换。 - SQL 写错表前缀。 建议执行前先
SELECT确认字段存在，再UPDATE，避免误伤。 - 序列化值手写错格式。
wp_capabilities的值是序列化字符串，字符数、标点、分号少一个都会失效，建议直接复制上面的标准值。 - 多站点覆盖 super admin 数组。 用 UPDATE 直接覆盖会把原有的其他超管一并清掉，应先读取再合并。
- 临时脚本忘了删。 用来赋权的 PHP 文件留在服务器上是严重安全隐患，用完必须删除。
- 清缓存后误判。 改完数据仍提示权限不足，先清一次对象缓存再测试，避免旧缓存干扰判断。
总结
迁移后提示「您没有足够的权限访问此页面」，多数时候不是账号真的被降权，而是用户元数据出了岔子——wp_usermeta 表没导全，或者 capabilities 字段的文件名还带着旧表前缀，让 WordPress 认不出你是管理员。修复的核心就是回到数据库，确认 wp_capabilities 记录存在、键名前缀正确、值里的 administrator 无误，需要时补上 wp_user_level，多站点再补 site_admins。只要按这个顺序排查，管理员权限很快就能找回来，后台也就能正常使用了。记住临时脚本用完即删，安全永远排在第一位。
还有一个容易被忽略的细节：如果你能进后台但只是部分菜单看不到，可以先到「用户 → 你的资料」里确认「角色」一栏是不是显示为管理员；若显示异常，也可以新建一个管理员账号来应急，再回头修复原账号。迁移前把用户表和管理员账号信息记录清楚，迁移后第一时间登录验证，能把权限问题挡在用户察觉之前。需要补充的是，修改任何用户数据前，都建议把 wp_users 和 wp_usermeta 两张表单独导出备份，万一改错也能立刻还原，不必重头再来。
