后台点“保存”后遮罩一直不消失，最没用的做法就是反复点按钮。商品保存不是一个小请求，它会触发 EAV 写入、图片处理、索引失效、插件和事件。页面没有弹错误，只能说明前端没有拿到可识别的响应。

第一步看那条保存请求究竟处于什么状态

打开浏览器 Network，重新保存一次，找到 product/save 请求。Pending 说明服务端还没结束；500 要看响应体和 exception.log；302 跳登录页多半是 Session 或 Form Key；200 却返回整页 HTML，则可能被 WAF、登录重定向或 PHP Warning 污染。

我会把请求开始时间记下来，再按同一时间段查日志，避免在几百 MB 的文件里盲搜：

tail -f var/log/system.log var/log/exception.log
journalctl -u php-fpm --since "5 minutes ago"

如果 PHP-FPM 日志显示 worker 超时或内存耗尽，先记录商品 SKU、图片数量和属性集。只有特定商品失败，通常是数据或媒体问题；所有商品都慢，才更像全局插件、数据库或基础设施。

Pending请求要查数据库正在等什么

SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUSG

长时间处于 Waiting for table metadata lock、更新价格索引表或 URL Rewrite 表，说明请求不是“死了”，而是在等锁。此时重启 PHP 只能让请求消失，锁的来源仍然存在。找到持锁事务和对应业务后再决定结束连接，别直接清空进程。

若数据库没有等待，我会在测试环境打开一次 Magento profiler，或者用 PHP-FPM slowlog 抓正在执行的调用栈。保存耗时稳定在同一个 Observer 或 Plugin，才有资格继续读那段代码。耗时飘忽且集中在远程域名，则检查 DNS、HTTP 超时和失败重试。很多“商品保存很慢”其实是在同步图片或通知 ERP，Magento 只是同步等待它返回。

图片较多的商品还要观察临时目录、磁盘 inode 和图片处理进程。上传预览成功并不代表保存时从 tmp 移动、生成角色图和缓存图都能完成。拿一个无图片的简单商品做对照，能快速把 EAV 保存与媒体处理拆开。

临时绕开插件时要一次只缩小一层

商品保存周围经常有 ERP 同步、自动生成 URL、图片压缩和审计插件。用 profiler 或插件日志确认耗时；在测试环境按模块逐个验证，不要在线上一次性禁用几十个模块。尤其检查 afterSave、aroundSave 中是否调用外部 HTTP 接口且没有超时。

还有一种情况是保存已经成功，前端在等待后续 Ajax 或页面跳转。刷新后若数据已落库，就检查返回内容是否混入调试输出，以及后台 JS Console 是否报错。最终修复标准不是“转圈没了”，而是保存请求耗时稳定、响应码正确、同类商品和大图商品都能完成，并且没有生成重复 URL 或半套索引数据。