Magento 2 后台修改配置后点击保存，突然提示 Invalid Form Key. Please refresh the page.。Form Key 是防止跨站请求伪造的令牌，它必须与当前管理员 Session 匹配。刷新一次偶尔能恢复，但如果持续出现，说明会话或请求链路不稳定。

先判断是所有页面还是某个大表单

如果简单配置也失败，重点查 Session、Cookie 与代理；只有商品、分类或包含大量字段的页面失败，检查 PHP 请求限制。post_max_size、max_input_vars 或 Web 服务器 body 限制可能截断 POST，使 form_key 字段根本没到应用。

php --ini
php -r 'echo ini_get("post_max_size"), PHP_EOL;
         echo ini_get("max_input_vars"), PHP_EOL;'

CLI PHP 配置不一定等于 PHP-FPM，最终要核对处理后台请求的 SAPI 配置和错误日志。

观察 admin Session Cookie 是否变化

在浏览器 Network 中比较打开表单与提交时的 Cookie。Domain、Path、Secure、SameSite 配错，HTTP 与 HTTPS 混用，或后台在 www/非 www 之间跳转，都会让提交使用另一会话。

清除浏览器 Cookie 只能验证旧 Cookie 冲突，不是长期修复。应检查 Base URL、Cookie Domain、后台路径和代理传递的原始协议。

多节点必须共享或固定 Session

页面由节点 A 生成 Form Key，保存请求落到节点 B，而两个节点使用各自本地文件 Session，就会校验失败。生产集群应使用共享 Session 存储，或在明确方案下使用粘性会话；同时保证所有节点加密配置一致。

Redis Session 连接不稳定、键被淘汰或 TTL 过短，也会造成相同现象。查看 Redis rejected connections、evicted keys 和 Magento Session 日志，不要只延长后台 lifetime。

页面停留太久和并发标签页也会影响

后台页面打开数小时后提交，Session 可能已过期。多个标签页跨登录、退出或切换账号，旧页面中的 Form Key 也会失效。系统应提示重新登录，而不是通过关闭 Form Key 验证解决。

不要禁用安全校验

Form Key 保护后台写操作。修改核心代码跳过校验、把任意 form_key 视为有效，会引入真实的 CSRF 风险。自定义后台表单应使用 Magento 提供的 FormKey Block/Provider，并通过标准后台路由提交。

修复后分别测试小配置、大表单、页面停留超过短期窗口、多节点轮询和 HTTPS 入口。提交时 Form Key 与 Session 始终一致，且错误日志没有请求截断，才能确认问题消失。