直接在 wp_users 表插入新管理员记录行不通，因 WordPress 还依赖 wp_usermeta 表中的 wp_capabilities 和 wp_user_level 等元数据；必须同步补全四条关键记录或使用 wp_insert_user 函数创建用户。
直接在 wp_users 表里插入新管理员记录行不通
phpmyadmin 是数据库管理工具，不是 wordpress 用户系统代理。直接往 wp_users 表里 insert 一条记录，即使密码用 wp_hash_password() 加密，也大概率登录失败——因为 wordpress 不只校验密码，还依赖 wp_usermeta 表里的 wp_capabilities 和 wp_user_level 元数据。缺这两项，账号连后台都进不去。
实操建议：
- 确保表前缀正确（不一定是
wp_，可能是wp123_，先看wp_options表的option_name值确认） - 先查出当前最高
ID：SELECT MAX(ID) FROM `wp_users`;，新用户 ID 设为该值 +1，避免主键冲突 - 密码必须用 WordPress 原生函数生成，不能用 MD5 或 bcrypt 直接填——phpMyAdmin 里没法调用 PHP 函数，所以得绕道
用 WordPress 自带的 resetpass.php 临时入口重置密码并提权
这是最稳妥、无需外部脚本的方法，适用于你已有数据库写权限但没 FTP/SSH 的场景。核心思路是：复用 WordPress 密码重置流程，让它自动写入正确的 wp_usermeta 数据。
操作步骤：
- 在网站根目录新建一个
resetpass.php文件，内容为：<?php define('WP_USE_THEMES', false); require_once('wp-load.php'); wp_set_current_user(1); // 假设 ID=1 是现有管理员，确保有权限 $user_id = wp_insert_user([ 'user_login' => 'newadmin', 'user_pass' => 'StrongPass123!', 'user_email' => 'admin@example.com', 'role' => 'administrator' ]); if (!is_wp_error($user_id)) { echo "User created: $user_id"; } else { echo $user_id->get_error_message(); } ?> - 访问
https://yoursite.com/resetpass.php，执行后会返回新用户的 ID - 立刻删掉
resetpass.php—— 这个文件留着是严重安全风险 - 如果报错
Call to undefined function wp_insert_user()，说明wp-load.php路径不对，改用require_once('./wp-blog-header.php');或完整路径
手动补全 wp_usermeta 表时字段值必须严格匹配
如果你坚持纯 phpMyAdmin 操作（比如环境限制无法上传文件），那必须一次性把 wp_usermeta 里四条关键记录补全，缺一不可。假设新用户 ID 是 999，表前缀为 wp_：
立即学习“PHP免费学习笔记（深入）”；
插入这四行（meta_key 和 meta_value 大小写敏感）：
构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等
-
wp_capabilities→a:1:{s:13:"administrator";b:1;} -
wp_user_level→10 -
wp_dashboard_quick_press_last_post_id→0（可选，但漏掉可能导致后台“欢迎面板”报错） -
wp_profile_update_time→1717027200（Unix 时间戳，用NOW()或当前时间即可）
注意：wp_capabilities 的序列化字符串不能手敲，必须用 PHP serialize() 生成，否则 WordPress 解析失败。临时可用在线工具生成，但更推荐用上面的 PHP 脚本方式。
创建后务必检查 wp_options 表里的 siteurl 和 home 设置
新管理员能登录，不代表能正常进后台。常见现象是点击“登录”后跳回首页或 404——大概率是 wp_options 表里 siteurl 和 home 值被改成错误地址（比如 http 被写成 https 但没配证书，或域名少了个 www）。
检查命令：SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');
修复方法：
- 如果值是
http://old-domain.com，而实际访问的是https://new-domain.com，必须同步更新这两项 - 修改后清空 WordPress 缓存（如果有插件）或重启 PHP-FPM，否则旧值可能被缓存
- 某些托管环境（如 SiteGround）会锁定
wp_options表写入，此时只能通过控制面板或联系支持修改
真正麻烦的从来不是加一行数据，而是 WordPress 把用户权限、站点配置、缓存状态全耦合在一起——动数据库前，先确认你改的是哪个环境的库，别在 staging 库上操作 production 的账号。
