本文解析 WooCommerce 结账页在 1080p 屏幕下 Shipping 选项不触发价格计算的异常现象，指出其本质是 Divi 主题中 sticky 列（.et_pb_column_1_tb_body）重复渲染导致 DOM 冲突，进而阻断 WooCommerce 前端事件绑定，提供禁用粘性属性及无侵入式替代方案。
本文解析 woocommerce 结账页在 1080p 屏幕下 shipping 选项不触发价格计算的异常现象，指出其本质是 divi 主题中 sticky 列（`.et_pb_column_1_tb_body`）重复渲染导致 dom 冲突，进而阻断 woocommerce 前端事件绑定，提供禁用粘性属性及无侵入式替代方案。
该问题表面表现为：用户添加商品至购物车后直达结账页，选择运输方式时运费数值无响应、不更新；但切换至 4K 分辨率或手动缩放浏览器（如 Ctrl + 滚轮缩小至页面全览）后功能恢复正常。这种分辨率/缩放强相关的异常，极易被误判为 JavaScript 兼容性或缓存问题——而真实原因深植于主题层的 DOM 渲染逻辑。
核心症结在于 Divi 主题对特定列（如 .et_pb_column_1_tb_body）启用了“Sticky”（粘性定位）功能。当该列进入视口临界点时，Divi 会克隆原始 DOM 节点并插入一个新 <div> 作为“sticky placeholder”，造成同一语义区块在 DOM 中重复存在。WooCommerce 的结账脚本（尤其是 wc-checkout.js）依赖唯一且稳定的 DOM 结构来监听 .shipping_method、.shipping-calculator-form 等关键元素的变更事件。一旦出现重复节点，事件委托可能绑定到已脱离文档流的旧节点，或因 jQuery 选择器匹配多个目标而行为不可控，最终导致 update_shipping_method 等 AJAX 请求未被触发。
✅ 正确解决路径分两步：
第一步：快速验证与临时修复
进入 Divi Builder → 编辑对应结账页 → 定位到报错的列模块 → 打开「Advanced」选项卡 → 在「Sticky Options」中关闭 Make this module sticky。保存并清空所有缓存（包括服务器端、CDN、浏览器），重新测试 1080p 下结账流程。若 Shipping 计算立即恢复，即可确认问题根源。
第二步：长期稳健替代方案
若需保留视觉上的“固定效果”，请避免使用 Divi 原生 sticky，改用 CSS position: sticky 配合精确容器约束（更轻量、无 DOM 复制）：
/* 推荐：纯 CSS sticky，安全可靠 */
.et_pb_column_1_tb_body {
position: -webkit-sticky !important;
position: sticky !important;
top: 20px !important; /* 根据顶部导航栏高度调整 */
z-index: 100;
}
/* 关键：确保父容器有明确高度/overflow，防止 sticky 失效 */
.woocommerce-checkout .et_pb_section {
overflow: visible; /* 避免父级 overflow: hidden 截断 sticky 行为 */
}⚠️ 注意事项：
- 切勿在 WooCommerce 结账页使用任何依赖 jQuery.clone() 或动态 DOM 插入的第三方“粘性插件”，它们同样可能引发重复 ID 或事件丢失；
- 启用 WP_DEBUG_LOG 并检查 wp-content/debug.log，确认无 PHP Warning: Duplicate ID 类错误；
- 若使用缓存插件（如 WP Rocket），需在「Excludes」中添加 /checkout/ 路径，避免结账 JS 被错误合并或延迟加载；
- 最终上线前，务必在 Chrome DevTools 的 Rendering > Paint flashing 和 Console 标签下验证：滚动时无异常重绘、无 Duplicate element id 警告、Network 面板中 wc-ajax=update_shipping_method 请求可正常发出并返回 200。
此问题并非 WooCommerce 核心缺陷，而是主题交互层的典型“副作用”。坚持“最小化 DOM 变更”原则，优先采用原生 CSS 方案而非框架级粘性逻辑，是保障电商流程稳定性的关键实践。
