真正原因是'user'@'localhost'与'user'@'%'为独立账户，改host字段不覆盖权限，且mysql认证优先匹配localhost；需drop旧账户并flush privileges，或分别创建两个账户授权。
phpMyAdmin里改Host字段为%不生效的真正原因
不是操作没保存，而是MySQL根本没用到那条记录——'user'@'localhost'和'user'@'%'是两条完全独立的账户，改前者的Host字段并不会“覆盖”或“迁移”权限，反而可能因密码插件不兼容、语句执行失败或缓存未刷新，导致新连接仍匹配旧的'user'@'localhost'并报错。
SELECT CURRENT_USER() 才是你实际连上的账户
很多用户以为自己在用-h 127.0.0.1连，就一定走'user'@'%'，其实不一定。MySQL认证顺序是：先匹配最具体的Host（如'user'@'192.168.1.100'），再是'user'@'localhost'（Unix socket专用），最后才轮到'user'@'%'。而CURRENT_USER()返回的是**被选中的那个账户**，不是你声明的用户名。
- 运行
SELECT CURRENT_USER();，如果返回'user'@'localhost'，说明你当前连接压根没走到%那条 -
SELECT USER();只告诉你登录时填了什么，不可靠 - 用
mysql -u user -p -h localhost→ 走 socket → 必定匹配'user'@'localhost' - 用
mysql -u user -p -h 127.0.0.1→ 走 TCP → 才可能匹配'user'@'%'（前提是'user'@'127.0.0.1'不存在）
phpMyAdmin界面改Host字段的实际行为很危险
在「用户账户」→「编辑权限」里把Host从localhost改成%，phpMyAdmin底层会尝试执行类似ALTER USER 'user'@'localhost' IDENTIFIED WITH ... HOST '%'的语句（MySQL 5.7+），但这不是标准语法，多数情况下会失败或静默降级为重建账户——而且：
- 旧密码哈希格式可能丢失，尤其MySQL 8.0+默认用
caching_sha2_password，而phpMyAdmin 5.2不兼容它，改完直接无法登录 - 如果
'user'@'%'已存在，会报#1396 - Operation ALTER USER failed，必须先DROP USER 'user'@'localhost' - 即使成功，也**不会自动执行
FLUSH PRIVILEGES**，内存缓存仍是旧的，新连接继续失败
正确做法：删旧建新，而不是改Host
要让%生效，就得让'user'@'localhost'彻底退出匹配队列。这不是“优化”，而是MySQL认证机制决定的硬规则。
- 确认存在冲突：
SELECT User, Host FROM mysql.user WHERE User = 'user'; - 如果只要远程访问，直接删掉本地账户：
DROP USER 'user'@'localhost';，再FLUSH PRIVILEGES; - 如果既要本地又要远程，就明确建两个：
CREATE USER 'user'@'localhost' IDENTIFIED BY 'pwd1';+CREATE USER 'user'@'%' IDENTIFIED BY 'pwd2';，再分别GRANT - 改完务必进「SQL」页手动执行
FLUSH PRIVILEGES;，别信界面提示的“成功”
最常被忽略的一点：改完Host字段后，你看到的只是phpMyAdmin界面上的显示变化，MySQL服务进程里对应的权限缓存、socket/TCP路由逻辑、甚至密码验证插件都完全没同步——它不是配置文件式的热更新，而是涉及账户元数据重建和运行时缓存重载的完整链路。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
