必须同时正确设置wp_capabilities和wp_user_level两条记录，且wp_capabilities需为合法序列化字符串，否则会导致权限异常、菜单错乱或登录跳转；推荐用update_user_meta()而非手动SQL操作。
直接改 wp_usermeta 表能加管理员权限，但必须同时写对两条记录
不能只改一条 wp_capabilities 就完事。wordpress 判断用户角色时，会检查两个 meta_key：一个是 wp_capabilities，另一个是 wp_user_level（虽已废弃但部分插件或旧主题仍会读取）。漏掉任意一个，可能导致后台菜单错乱、某些管理功能不可用，甚至登录后立即跳转回登录页。
实操建议：
-
wp_capabilities的值必须是序列化数组字符串，例如a:1:{s:13:"administrator";b:1;}，不能手写 JSON 或 PHP 数组语法 -
wp_user_level建议设为10（对应管理员），避免兼容性问题 - 表前缀不一定是
wp_，请先查$table_prefix配置，比如可能是myblog_，对应字段就是myblog_capabilities - 操作前务必备份
wp_usermeta表，误写序列化字符串会导致该用户无法登录
用 update_user_meta() 比手动 SQL 更安全
直接执行 SQL 容易因序列化格式错误导致用户元数据损坏；而 update_user_meta() 会自动处理序列化，且触发相关 action 钩子（如 added_user_meta），降低后续权限逻辑异常风险。
常见错误现象：用 phpMyAdmin 手动更新后，用户能进后台但看不到「仪表盘」或「设置」菜单——大概率是 wp_capabilities 字符串反序列化失败。
实操建议：
- 在主题的
functions.php或临时插件中运行一次即可：update_user_meta(123, 'wp_capabilities', array('administrator' => true));（把123换成目标用户的ID） - 接着补上 user_level：
update_user_meta(123, 'wp_user_level', 10);
- 执行完立刻删掉这段代码，避免重复运行覆盖其他角色
- 不要在
init钩子中无条件调用，否则每次请求都重写，影响性能
为什么改了权限却没生效？检查用户是否被其他插件锁定
有些安全插件（如 Wordfence、iThemes Security）或多站点配置会主动拦截或覆盖角色变更。即使数据库里写对了，前端也可能显示“您没有权限访问此页面”。
使用场景：你确认 wp_capabilities 值正确、也刷新了缓存，但用户登录后仍只有编辑者权限。
实操建议：
- 临时停用所有安全类插件，再测试是否生效
- 检查是否启用了「强制角色同步」类插件（如 Members 插件勾选了 “Lock roles”）
- 查看
wp_options表中是否有wp_roles选项被篡改（极少见，但发生过） - 用 WP-CLI 快速验证：
wp user get 123 --field=roles，它绕过插件钩子，直接读数据库值
别忽略缓存和对象缓存的影响
WP-CLI 或数据库改完后，用户可能仍看到旧权限，不是数据库没改对，而是 WordPress 把用户角色缓存在内存或 Redis/Memcached 里了。
性能影响：对象缓存未失效时，current_user_can() 等函数返回的仍是旧结果，持续几分钟甚至更久。
实操建议：
- 如果是本地开发环境（无持久化对象缓存），只需清空浏览器 Cookie 并登出重登
- 如果启用了 Redis/Memcached，执行
wp cache flush（WP-CLI）或联系主机商清空对象缓存 - 不要依赖「禁用插件→改库→启用插件」这种流程，插件激活时可能重新同步角色，覆盖你的修改
wp_capabilities 就够了，结果 wp_user_level 没同步，或者序列化字符串手写错了，然后花半天排查权限逻辑。 
