安全修改wp_capabilities值需用PHP序列化格式（如a:1:{s:13:"administrator";b:1;}），而非JSON；必须同步更新wp_user_level，且优先使用update_user_meta()函数或后台编辑，避免手动SQL出错。
直接改 wp_usermeta 表里的 wp_capabilities 字段就能切换用户角色，但手动拼 json 容易出错、漏引号或括号不匹配，导致用户登录后白屏或权限异常。
怎么安全修改 wp_capabilities 的值？
WordPress 用户角色权限实际存在 wp_usermeta 表中，字段是 wp_capabilities，值为序列化数组（不是 JSON）。phpMyAdmin 默认显示的是 PHP 序列化字符串，比如：
a:1:{s:13:"administrator";b:1;}
这不是 JSON，不能用 JSON 格式编辑。常见错误是粘贴成 {"administrator":true}，保存后 WordPress 读取失败，用户失去所有权限。
- 必须用 PHP
serialize()格式，不能手写或转 JSON - 推荐在本地 PHP 环境里生成正确值：运行
echo serialize(['administrator' => 1]);得到结果再复制 - 若只是切换角色（如从 subscriber 改为 editor），优先用 WordPress 后台「用户 → 编辑」操作，避免直改数据库
- 如果必须 DB 操作，先备份
wp_usermeta表，再执行 UPDATE
为什么改完 wp_capabilities 用户还是没权限？
除了 wp_capabilities，WordPress 还依赖 wp_user_level（已废弃但部分旧插件仍读取）和角色对应的 wp_options 中的 wp_user_roles 结构。单独改 capability 不生效的常见原因：
-
wp_user_level值未同步更新（例如 editor 对应 7，contributor 是 1） - 当前站点启用了多站点（Multisite），角色存储在
wp_sitemeta而非wp_usermeta - 插件（如 User Role Editor、Members）覆盖了默认角色逻辑，直接改表被插件缓存或拦截
- MySQL 字符集为
utf8mb4时，序列化字符串里中文或 emoji 可能截断，导致 unserialize 失败
如何验证修改是否生效？
改完别急着退出 phpMyAdmin，立刻查两条记录确认：
立即学习“PHP免费学习笔记（深入）”；
- 执行
SELECT meta_value FROM wp_usermeta WHERE user_id = 123 AND meta_key = 'wp_capabilities';，看输出是否是合法序列化字符串（开头是a:、s:、i:等） - 再查
SELECT meta_value FROM wp_usermeta WHERE user_id = 123 AND meta_key = 'wp_user_level';，确保和目标角色匹配（admin=10, editor=7, author=2, contributor=1, subscriber=0） - 登录对应用户账号，访问后台「仪表盘 → 更新」或「文章 → 新建」，观察是否出现「您没有权限执行该操作」提示
最隐蔽的坑是：某些托管环境（如 SiteGround、WP Engine）启用了对象缓存，改完表后需清空 OPcache 或 Redis 缓存，否则旧 capability 仍被读取。
