后台改了一个配置，提示保存成功，刷新页面却还是旧值。这个问题不要先清全站缓存，我通常先回答两个问题：POST 请求提交了什么，数据库刚保存完到底有没有新值。
保存前把scope和配置路径记下来
同一个字段在 Default、Website、Store View 可以有三份值。先确认左上角当前作用域，以及“Use Default”是否勾选。然后从页面字段或 system.xml 找到真实配置路径。
bin/magento config:show section/group/field
SELECT scope, scope_id, path, value
FROM core_config_data
WHERE path = 'section/group/field';保存后立刻查数据库。新值从来没写进去，就看 backend model 校验、ACL、POST 参数和异常日志；数据库里已经是新值，页面却显示旧值，再查读取作用域、config cache 和应用连的是不是同一个数据库。
读写分离环境要从处理保存请求的节点和处理刷新请求的节点分别确认数据库连接。写入主库后立刻从延迟副本读取，会短暂看到旧值；如果刷新几秒后又恢复新值，就是明显信号。后台配置读取通常不应该在不保证一致性的副本上完成。
数据库里刚改好，几秒后又变回去，就找覆盖源
容器启动脚本、部署任务、配置同步程序都有可能把旧值重新写回。连续查询该 path，并对照部署和 cron 时间。不要一直在后台重复保存，否则只会让覆盖动作更难看清。
自定义 backend model 也可能在 afterSave 中把一个可视字段拆成多个配置值，或者根据另一个开关强制清空。Network 里的 POST 有新值、数据库从未出现新值时，把该字段配置类和保存事件一起搜出来，比继续怀疑浏览器缓存有效。
再检查 app/etc/config.php、env.php 和环境变量。被配置管理锁定的 path 应该从代码或部署变量修改，后台不是它的事实来源。使用 Magento 的配置状态命令确认是否被锁，不要直接删配置文件里的节点。
修完后必须走一次正常发布
我会在正确 scope 保存或更新部署配置，清理 config cache，再从另一台 Web 节点读取一次。随后执行一次完整部署或重启容器，确认值没有被旧变量覆盖。
最终记录这个配置到底由数据库、config.php 还是环境变量维护。下次再改时团队知道去哪里动手，比“这次刷新终于没变回去”更重要。
多网站配置还要拿两个 store view 交叉验证：目标站点读到新值，未修改站点继续继承原值。这样能证明 scope_id 没写错，也不会为了修一个站点把全局配置一起覆盖。
