1045错误本质是认证失败而非连接不通，主因是宝塔所填账号密码与MySQL中authentication_string字段不匹配，或用户未被授权从当前host（如%、localhost、127.0.0.1）登录。
1045 错误本质是认证失败，不是连接不通 —— 宝塔面板里填的账号密码，和 MySQL 实际存储的 authentication_string 或 password 字段不匹配，或者该用户没被授权从当前 host（比如 % 或 localhost）登录。
为什么宝塔里填对了密码还是报 1045？
常见原因不是“输错了”，而是权限记录本身已损坏或不一致：
-
root用户在mysql.user表里有多个记录，比如'root'@'localhost'、'root'@'127.0.0.1'、'root'@'%'，但只有其中一条的authentication_string有效，其余为空或过期哈希； - MySQL 5.7+ 废弃了
password字段和PASSWORD()函数，但宝塔旧版脚本或手动执行的 SQL 还在用，导致写入无效值； - 宝塔默认用
root@localhost连接，但你重置时改的是root@%，host 不匹配直接拒绝； - 防火墙或
skip-networking开启，导致本地 socket 连接被绕过，实际走的是 TCP，而localhost在 MySQL 里特指 socket，127.0.0.1才是 TCP —— 这会导致 host 判定失败。
怎么安全地重置 root 密码并确保宝塔能连
不要直接删 my.cnf 里的 skip-grant-tables 后重启就完事，必须确认生效 host 和字段：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 停止 MySQL：
systemctl stop mysqld（宝塔环境通常用mysqld，不是mysql）； - 编辑
/www/server/mysql/my.cnf，在[mysqld]下加一行：skip-grant-tables，保存； - 启动 MySQL：
systemctl start mysqld； - 免密登录：
mysql -u root（不加-p）； - 执行以下三步（顺序不能错）：
USE mysql;<br>UPDATE user SET authentication_string = '' WHERE user = 'root';<br>FLUSH PRIVILEGES;
； - 退出后删掉
my.cnf里的skip-grant-tables，再systemctl restart mysqld； - 重新登录：
mysql -u root -p，此时会提示输入新密码 —— 输入你想设给宝塔用的密码； - 进库后立刻执行：
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的密码';<br>ALTER USER 'root'@'127.0.0.1' IDENTIFIED BY '你的密码';<br>FLUSH PRIVILEGES;
（这两条覆盖 socket 和 TCP 两种 localhost 场景）。
宝塔连接设置里最容易漏的三项
即使密码重置成功，宝塔仍可能报 1045，因为它的连接逻辑比命令行更严格：
- 宝塔「数据库」页添加新库时，默认填写的主机是
127.0.0.1，但如果你只改了'root'@'localhost'的密码，它连不上 —— 必须同步更新'root'@'127.0.0.1'； - 宝塔后台「软件商店 → MySQL → 设置 → 配置修改」里，检查
bind-address是否为127.0.0.1或0.0.0.0，不能是localhost（MySQL 不认这个 bind 值）； - 如果启用了「MySQL 安全加固」插件或宝塔自带的「强制密码强度」，新设密码必须含大小写字母+数字+特殊符号，否则
ALTER USER会静默失败，表面成功实则没写入。
最常被忽略的一点：改完所有 SQL 和配置后，一定要在宝塔「数据库」页面点击对应用户的「修改密码」按钮，而不是只改 MySQL 侧 —— 宝塔会校验自己数据库里存的密码哈希是否与 MySQL 一致，不一致就拒绝连接，且错误仍是 1045。
