结账页是 WooCommerce 站点最不能慢、也最不能出错的页面。和内容页不同，结账页不能靠整页缓存提速：每一步都要实时计算价格、库存、运费、税费和优惠，还要调用支付接口。排查结账慢的关键，是把「点击下单到看到结果」拆成几段，分别测量、分别处理。下面的步骤建议先在预发环境执行，涉及订单与支付的操作不要直接在生产环境试错。
先确定慢在哪一段
打开浏览器开发者工具的 Network 面板，勾选 Preserve log，完整走一遍「加入购物车 → 打开购物车 → 进入结账 → 修改地址 → 提交订单」，记录每个请求的耗时。重点关注这些请求：
?wc-ajax=get_refreshed_fragments：购物车片段刷新，经典主题中常见；?wc-ajax=update_order_review：经典结账页修改地址或配送方式时重新计算订单；?wc-ajax=checkout：经典结账页提交订单；/wp-json/wc/store/v1/开头的请求：区块购物车和区块结账使用的 Store API；- 支付网关的前端脚本、跳转与回调请求。
哪个请求慢，就先处理哪一段。所有 wc-ajax 请求都慢，通常是站点整体的后端问题；只有某一个慢，多半与对应的计算环节或某个插件有关。
第 1 步：确认结账相关页面没有被缓存
结账慢和结账出错经常同时出现，根源往往是缓存配置错误：
- 页面缓存和 CDN 必须排除购物车、结账、我的账户页面。以 WooCommerce 设置中实际指定的页面为准，不一定是默认的 /cart/、/checkout/；
- 带有
woocommerce_items_in_cart、woocommerce_cart_hash、wp_woocommerce_session_开头 Cookie 的请求应绕过页面缓存； - 不要让 CDN 缓存或合并
wc-ajax与/wp-json/wc/store/请求。
用无痕窗口加购后访问结账页，查看响应头，确认返回的是未命中缓存的动态响应。
第 2 步：处理购物车片段请求
经典主题中，get_refreshed_fragments 用于在页面被缓存的情况下刷新迷你购物车。它本身不能缓存，访问量大时会产生大量 PHP 请求。较新版本的 WooCommerce 已不再默认在所有页面加载购物车片段脚本，如果你仍然在每个页面看到这个请求，多半是主题或某个插件主动加载的。处理思路：
- 确认主题是否真的需要在每个页面实时刷新迷你购物车；
- 只在购物车不为空时触发刷新，或改用区块主题的迷你购物车区块；
- 改动后验证加购、删除、修改数量时，购物车数字是否仍然正确。
第 3 步：运费、税费与优惠计算
修改地址或配送方式时，WooCommerce 会重新计算运费和税费。这一段慢的常见原因有：
- 实时运费插件每次计算都同步请求物流商接口，接口一慢就直接卡住结账；
- 运费区域、规则或表格运费的条目非常多；
- 多个优惠券、会员价、动态定价插件挂在同一个钩子上，反复计算购物车。
Query Monitor 会在 AJAX 请求的响应中附带调试信息，可以在浏览器控制台查看 update_order_review 请求中的慢查询和外部 HTTP 请求，找出是哪个组件在拖慢计算。外部接口应设置合理的超时并缓存结果，不能让一次接口超时拖住整个下单流程。
第 4 步：支付网关与订单提交
- 提交订单慢，先看
wc-ajax=checkout或 Store API 的 checkout 请求耗时，再判断是卡在订单创建、跳转支付页，还是支付回调； - 在「WooCommerce → 状态 → 日志」中按支付网关筛选日志，查看接口响应时间和报错；
- 服务器访问支付接口受限（出站防火墙、DNS 解析慢、跨境网络）时，会表现为提交订单长时间转圈。可以在服务器上用
curl -o /dev/null -s -w "%{time_connect} %{time_starttransfer}\n" https://支付接口域名/直接测试连接时间； - 订单提交后触发的邮件、CRM 同步、库存同步等操作，尽量交给 Action Scheduler 异步执行，而不是同步阻塞下单请求。
第 5 步：会话、计划任务与数据库
- WooCommerce 会话保存在
wp_woocommerce_sessions表中，过期会话由计划任务清理；WP-Cron 不正常时这张表会持续膨胀。可以用wp db query "SELECT COUNT(*) FROM wp_woocommerce_sessions;"查看规模，必要时在「WooCommerce → 状态 → 工具」中清理客户会话（会清空所有访客的购物车，请在低峰期操作）。 - 在「WooCommerce → 状态 → 计划操作」中检查失败或积压的任务，积压严重时数据库压力会直接影响结账。
- 高性能订单存储（HPOS）可以减轻订单读写对
wp_posts和wp_postmeta的压力。新站默认启用；老站切换前要确认支付、物流、ERP 等插件全部兼容，并在预发环境完成数据同步与测试。 - 启用 Redis 对象缓存可以减少重复查询，启用后要回归测试购物车和会话是否正常。
第 6 步：插件冲突与前端脚本
结账页常加载大量第三方脚本：统计、客服、营销弹窗、地址自动补全等。在预发环境用排障模式逐个停用非必要插件，对比结账各请求的耗时。前端脚本报错还会导致「点击下单没有反应」，排查时要同时查看浏览器控制台。
修复顺序与验收清单
- 先修缓存排除，保证结账结果正确；
- 再处理运费、支付、地址校验等外部接口的超时与缓存；
- 然后清理会话和计划任务积压，启用对象缓存；
- 最后精简插件和前端脚本。
验收时用真实商品、真实配送地址和测试支付方式完整下单，登录与未登录状态各测一遍，记录每一段请求的耗时；确认订单、库存、邮件通知和后台订单状态都正确。
延伸阅读：WooCommerce 性能优化专题、WooCommerce 实践清单、对象缓存 Redis 是什么、插件冲突排查流程。缓存插件与 WooCommerce 配合的官方说明见 WooCommerce 缓存配置文档。
常见问题
结账页能不能用页面缓存加速？
不能整页缓存。结账页需要实时计算价格、库存和运费，应当排除页面缓存，通过对象缓存、减少外部请求和精简插件来提速。
区块结账和经典结账哪个更快？
两者的请求方式不同，不能一概而论。区块结账基于 Store API，扩展插件的兼容性需要逐个确认；切换前先在预发环境对比实际耗时和兼容情况。
结账慢会影响订单数据吗？
请求超时可能导致用户重复提交，或出现支付成功但订单状态未更新的情况，需要同时检查支付回调日志和订单备注。
结账问题涉及支付与订单数据，建议在预发环境排查。需要协助时可以 申请免费诊断。
