客户填写完结账信息，点击 Place Order 后提示 reCAPTCHA validation failed 或无响应。关闭验证码会降低防护，应先区分前端未生成 Token、Token 已过期、action 不一致和后端验证请求失败。

固定复现条件

在测试订单中记录浏览器 Console、提交请求、非敏感错误码、页面域名和 reCAPTCHA action。不要记录 Token、客户地址或密钥。比较默认 Checkout 与第三方一步结账。

php bin/magento module:status | grep -i captcha
php bin/magento config:show recaptcha_frontend/type_for/place_order
grep -R --line-number 'place_order|reCaptcha' app/code app/design 2>/dev/null
grep -RniE 'captcha|recaptcha|validation' var/log | tail -n 100
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' https://www.google.com/recaptcha/api/siteverify

根据证据定位

请求没有 Token，查 JS 组件和 CSP；后端返回 hostname/action 不符，查域名与配置；偶发过期说明 Token 生成过早；仅代理后失败，检查源站出网、客户端 IP 与可信代理。第三方结账可能绕过标准 provider。

修复与回滚

使用目标 Magento 版本支持的 reCAPTCHA 类型，在真正提交前获取对应 action 的短期 Token，并按扩展提供的集成点挂载。修复 CSP 与出网，不在日志写 Secret；需要应急降级时应限时、受监控并保留其他风控。

验收

成功下单、失败后重试、页面停留超时、多个支付方式和移动端都测试；无 Token 与伪造 Token 必须被拒绝，正常客户不能产生重复订单。

生产环境操作前的检查

处理“Magento 2 reCAPTCHA 阻止客户提交订单”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层证据通过标准
入口 URL、状态码、请求 ID、节点 路由与协议一致
应用 异常堆栈、模块、作用域 无新异常且可重复
数据 主键、时间、关联行数 关系完整无重复副作用
业务 正常、失败与重试路径 最终状态一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。