先做這件事
WooCommerce 結帳失敗：不要在沒有備份時連續試錯
結帳失敗可能發生在欄位驗證、JavaScript、Session、訂單建立、付款跳轉或 Webhook。要以同一筆測試訂單串起瀏覽器與伺服器紀錄。
本文聚焦「先建立測試訂單與時間線，再檢查 Console、Network、訂單備註與金流日誌。」。對應的使用情境是：客戶無法完成結帳，希望定位前端、訂單或金流問題。。排查時請保存每一步的時間、畫面與日誌差異，才能把同時發生但無關的變更排除。
排查原則：先保存錯誤與現況，再從低風險、可回復的檢查開始；一次只改一個變因。
問題症狀
- 按下結帳沒有反應
- 訂單建立但付款狀態未更新
- 特定裝置或付款方式失敗
先不要清除所有證據。保存 HTTP 狀態、錯誤時間、瀏覽器 Network 與最近部署紀錄，再判斷問題在前端、WordPress 或主機層。
可能原因
- 01JavaScript 或欄位外掛衝突。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 02結帳頁被錯誤快取。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 03金流 API／Webhook 或伺服器時間問題。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
修改前備份
先建立檔案與資料庫完整備份，下載到站外位置並確認可以讀取；另保存外掛、主題、PHP 版本與目前錯誤畫面。
除了檔案和資料庫，另保存外掛、主題、PHP、WordPress 版本與目前設定畫面，才能在回復時重建相同環境。
由低風險到高風險的排查順序
-
1. 在測試環境建立最小商品與測試付款
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
2. 保存 Console、Network 與失敗時間
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
3. 檢查訂單備註與 WooCommerce 日誌
每完成一步就重測同一個最小重現，確認問題是否改變。 -
4. 排除頁面快取與外掛衝突
每完成一步就重測同一個最小重現，確認問題是否改變。 -
5. 依金流官方文件核對回傳與 Webhook
只把已在測試環境通過的最小變更套用到正式站，並立刻跑回歸測試。
低風險檢查應先於版本切換、資料庫修改與全站停用。若證據已排除某一層，不要為求快速又重做高風險動作。
如何確認修復成功
測試訂單從加入購物車到正確狀態完成，庫存與信件符合流程，沒有重複扣款。
- 以原本的最小重現步驟再次測試。
- 檢查首頁、登入、REST API、表單與網站最重要的交易流程。
- 查看 PHP error log、瀏覽器 Console 與 Network 是否新增錯誤。
- 以 390px 手機寬度確認沒有版面級橫向溢位。
把症狀與證據對成一條排查路徑
| 目前看到的症狀 | 先驗證的原因 | 最小安全動作 |
|---|---|---|
| 按下結帳沒有反應 | JavaScript 或欄位外掛衝突 | 在測試環境建立最小商品與測試付款 |
| 訂單建立但付款狀態未更新 | 結帳頁被錯誤快取 | 保存 Console、Network 與失敗時間 |
| 特定裝置或付款方式失敗 | 金流 API／Webhook 或伺服器時間問題 | 檢查訂單備註與 WooCommerce 日誌 |
這張表不是用來直接判定根因，而是把「看到什麼、要查什麼、哪個動作可回復」放在同一列。若第一列的證據不成立，就不要跳到高風險修改。
如何還原
若修改後問題加劇，立即還原剛才變更的檔案或設定；無法確定影響範圍時，用已驗證備份在測試環境還原，不要在正式站連續試錯。
回退需與部署方式一致：檔案、資料庫 schema 與設定若同時改變，就要使用相容版本一起回復。
何時應停止自行操作
若可能重複扣款、涉及真實卡號或金流商要求正式帳號操作，停止自行測試並聯絡金流與專業人員。
停止不是放棄，而是避免把可復原的錯誤變成停機、資料損失或資安事件。準備好時間線、備份、錯誤日誌與已嘗試步驟，能顯著縮短專業人員的診斷時間。
常見問題
可以直接在正式站測試嗎？
不建議。先備份並在測試環境重現，正式站只套用已驗證的最小變更。
需要關閉所有外掛嗎？
不應在沒有計畫時一次關閉。先保存清單，再用隔離或健康檢查方式逐步排除。
修好後要做什麼？
清除必要快取、重測主要流程、保存變更紀錄並確認監控沒有新錯誤。
官方文件與查核來源
以下文件用於核對 WordPress、WooCommerce、PHP 或資料庫行為。第三方外掛與主機設定仍需查閱該產品當前版本的正式文件。