English
繁體中文
多數 WooCommerce 3D 配置器專案，是在客人配完、按下加入購物車的那一刻開始悄悄失敗的。3D 看起來對、選項會動，然後訂單進到倉庫時變成一個通用商品加一段沒人解析得了的文字備註。按鈕之前的一切都會在示範裡被反覆檢視，按鈕之後的，通常不會。
WooCommerce 讓這一段看起來很好開始、實際收尾很瑣碎，因為它的訂單模型是為「固定一組變體的商品」設計的，不是為「由一堆選擇拼出來的成品」設計的。機制可以解決，而它決定的差別是：配置器會賣東西，還是會生電話。
為什麼 WooCommerce 變體裝不下一個配置
WooCommerce 的可變商品期待的是一張有限的屬性矩陣：選尺寸、選顏色，跑出一個帶自己 SKU、價格與庫存的變體。加上第三個屬性的八個值、第四個屬性的五個值，矩陣就爆炸成一堆大多不該存在的組合，而 WooCommerce 希望你為每一個建檔、定價、管理庫存。
配置的行為不一樣。有些組合不只是不受歡迎，而是不合法。某個轉角模組接不上某種扶手，某種飾面只配某一系列骨架。WooCommerce 沒有「拒絕」這個概念，於是店家只有兩條路：建一部分變體、其餘全部落到預設值，或者乾脆繞過變體、把選擇寫到別的地方。真實專案大多選第二條，資料設計就從那裡開始。
配置怎麼走到訂單
最輕的做法，是把選擇寫進一般購物車項目的 line-item meta：一段 JSON 掛在訂單行上，每個選中的選項一條。開源外掛就是這樣做、也寫得很明白：配置以 line-item meta 儲存，會出現在訂單詳情與確認信裡。這樣可行、不必改核心，對「後台就是一個人在讀訂單」的店已經夠用。
重一點的做法，是把配置表示成自己的訂單行型別，模組清單變成結構化的子資料，而不是一整段 blob。這適合需要點料、需要算零件的工廠，成本也高一些，因為購物車和訂單的呈現都得認識這個新形狀。
有些專案則完全不建訂單行。當定價需要人判斷，或者這個組合超出購物車能表達的範圍，配置就以報價請求的形式離開，帶著結構化 payload 和一條連回已存配置的連結。訂製家具和工業設備常見這個模式，取捨也很誠實：你用即時結帳換來「不必假裝機器什麼都報得出價」。如果規則那一層還不熟，產品配置器規則引擎講的是在任何資料寫進訂單之前、決定什麼組合合法的部分。
payload 裡該裝什麼
一段寫著「橡木、黃銅、大」的 payload 只是備註。營運團隊能據以處理的 payload 帶的東西更多。
每一個選中的選項需要穩定編碼，而不是顯示名稱，因為名稱會被翻譯、被改名，而編碼得活著走到產線。尺寸要以計算後的值放進去，而不是產生它的選項名字，因為工廠讀的是公釐。任何價格增減要與基礎商品分開列，這樣發票才解釋得清楚。payload 還應該帶版本標識，因為某個模組退役的那一天，舊的已存配置必須能和現行的區分開來。
有一個問題值得早點回答：半年後，誰還讀得懂這段 payload。如果答案只有當初寫它的那位工程師，那格式就是錯的。
沒人預先規劃的三處碰撞
庫存是第一處。完成後的配置可能根本不是一個庫存品項，所以庫存要嘛存在零件層級，要嘛這件是訂製、庫存應該停用而不是設成零，否則 WooCommerce 會很樂意擋掉一張工廠明明做得出來的單。
可變商品是第二處。外掛文件常常寫得很直接：支援的是簡單商品，可變商品未經測試。這件事重要，因為很多目錄早就按變體組織好了。把一條要上配置的產品線搬離變體、或把兩者接起來，是實實在在的工作，該進估算，不該留到第六週。
稅金與運費類別是第三處，也最不光鮮。一個分兩箱出貨的配置，套不進單箱的運費類別；一個大型組件可能跨過母商品從來沒碰到的稅額門檻。這些都不會擋第一次上線，但都會擋第二次。
已經跑在變體上的目錄怎麼遷
店家很少從空白佈景主題開始，目錄跑得順的，通常已經在變體上投資過了：色卡、尺寸表、每個變體的圖片。為了配置器把這些拆掉，是一個比配置器本身更大的決定。
可行的中間路線，是保留簡單商品不動，只對「選擇真的影響購買」的那條產品線做配置。同時賣現貨與訂製的店，可以讓一般可變商品與配置商品並存在同一個站上，前提是兩者的訂單 payload 一致，倉庫不必學兩套讀法。
整份目錄都是訂製的店，把變體遷成組件庫通常值得做，因為那麼大的矩陣，每次布料停產你都在付維護費。無論走哪條，遷移都該在估算裡佔一個獨立階段，並且立一條規矩：排定要做配置的產品線，誰都不准再加新變體。
工廠該看到什麼
從工廠真正在用的那張紙往回推。產線照裁切清單走，payload 就得生得出裁切清單。產線照料號走，每個模組就都要有料號，而且編號規則必須由生產端給，不是網站團隊自己編，這在工業設備 3D 配置器的專案裡，我們當成硬性輸入。如果是業務每一單都重新報價，那誠實的輸出就是報價請求，硬套一個加入購物車流程，只會造出所有人都會忽略的假精確。
這套模式我們在兩個平台上都做過，WooCommerce 與Shopify 家具配置器的差別，主要在訂單資料最後落在哪：WooCommerce 傾向留在 WordPress 裡，Shopify 傾向推到 headless 前端再回來。資料契約，也就是模組編碼進、結構化訂單出，兩邊是同一件事。
契約對了，WooCommerce 3D 配置器就從一次視覺升級變成營運工具。契約錯了，你只是替一間還在用 email 接單的店，加了一個漂亮的檢視器。如果專案在路上、而你不確定訂單這一側要做到多深，告訴我們工廠現在讀的是什麼，我們就從那裡往回推。可以先聊聊你的流程。
FAQ
問：WooCommerce 外掛能撐起真正的 3D 配置器嗎？
顏色、材質與簡單選項切換，在簡單商品上可以，而且便宜。外掛文件通常也講得很清楚：可變商品不屬官方支援範圍、選擇以 line-item meta 儲存；對「人讀訂單」夠用，對自動化生產不夠。
問：每個配置都要建成變體嗎？
不用，而且通常不該。把每種合法組裝都建成變體，會造出養不起的矩陣。常見做法是基礎商品加上結構化的 line-item 資料，或者在需要人工看價時走報價請求。
問：配置怎麼出現在訂單通知信裡？
line-item meta 預設會渲染在訂單詳情與確認信裡，這也是輕量做法受歡迎的原因。那裡的標籤要寫給打包的人看，不是寫給測試 payload 的工程師看。
