直接改wp_capabilities字段可恢复权限，但手写序列化字符串极易出错导致白屏或登录失败；需同步更新wp_user_level值（如administrator对应10）、确认多站点下数据在wp_sitemeta表、排除插件劫持及utf8mb4字符截断问题，并用PHP serialize()生成合法字符串后三步验证：查capabilities值、查user_level值、隐身窗口测试/post-new.php权限。
直接改 wp_capabilities 字段就能恢复权限，但手写序列化字符串几乎必然出错——白屏、登录失败、菜单消失全由此引发。
为什么改了 wp_capabilities 用户还是没权限？
WordPress 不只看这个字段，它还依赖配套值和上下文：
-
wp_user_level字段虽已废弃，但部分旧插件（如某些 SEO 或会员工具）仍会读取它；administrator对应值应为10，editor是7，填错会导致后台功能被静默限制 - 多站点（Multisite）环境下，角色数据存在
wp_sitemeta表，而非wp_usermeta；查wp_usermeta会漏掉真实配置 - 插件（如 User Role Editor、Members）可能劫持角色逻辑，直接改表后缓存未刷新，或被插件的钩子覆盖回旧值
- MySQL 字符集为
utf8mb4时，若序列化字符串含 emoji 或中文，unserialize()可能中途截断，返回false—— 表现为权限全丢，且无报错
怎么安全生成正确的 wp_capabilities 值？
别手写，也别用 JSON 格式粘贴。PHP 序列化极其脆弱，一个冒号错位或引号不闭合就全崩。
- 本地搭个最小 PHP 环境（哪怕 just
php -a），运行：echo serialize(['administrator' => 1]);→ 得到a:1:{s:13:"administrator";b:1;} - 如果目标是
editor，用echo serialize(['editor' => 1]);，别试图手动改字符串里的administrator为editor—— 长度变化会破坏结构 - 确认输出开头是
a:（数组）、s:（字符串）或i:（整数）；如果开头是{，说明你误用了 JSON - 复制结果时，用纯文本编辑器（如 VS Code、Notepad++）粘贴检查，确保没有不可见空格或中文标点
改完必须立刻验证的三件事
别关 phpMyAdmin 页面，就在当前窗口执行验证，避免“以为修好了其实没生效”：
- 查
wp_usermeta：运行SELECT meta_value FROM wp_usermeta WHERE user_id = 123 AND meta_key = 'wp_capabilities';，确认返回值是合法序列化字符串，且内容匹配目标角色 - 查
wp_user_level：同一user_id下，meta_key = 'wp_user_level'的meta_value必须对应（例如administrator → 10） - 清浏览器缓存后，用隐身窗口重新登录；访问
/wp-admin/post-new.php，不是看菜单有没有，而是看是否弹出「您没有权限执行该操作」——这才是真实权限反馈
最常被跳过的动作是核对 user_id 和表前缀。迁移过站点或启用了多站点，user_id = 1 很可能不是你的管理员；而 wp_ 前缀在安装时可能设为 abc_ 或其他，硬编码写死会改错表。
立即学习“PHP免费学习笔记（深入）”；
