Shopify Theme 客製不等於直接修改 Liquid。許多需求能用 Theme editor、template、section 或 app block 完成，只有流程和資料超出既有能力時才需要寫程式。先選對改動層級，之後更新 Theme、移除 App 和交接給營運團隊都會簡單許多。
開始前，把需求寫成使用情境。例如「內容團隊要在商品頁加入可排序的材質說明」，比「做一個漂亮的產品模組」更容易決定資料放哪裡、誰能編輯和如何驗收。
第一層：先用 Theme editor 設定
顏色、字體、間距、logo、按鈕樣式和既有 section 的排列，通常應先使用 Theme settings。設定層改動不需要分支程式，也比較容易由品牌自行維護。若只為了改一段文字就把內容寫死在 Liquid，未來每次活動都要找工程師。
但設定不是越多越靈活。應保留品牌允許的選項，避免每個 section 都能任意改色、字級和間距，最後讓同一網站出現多套視覺規則。
第二層：新增 template、section 與 block
當既有模組無法表達內容，可以新增 section 或 block。Shopify Theme architecture將 templates、section groups、sections、blocks、snippets 和 assets 分開管理。切分時要讓模組有清楚責任，例如商品賣點、比較表或媒體文字，不要建立一個塞進所有版型的萬用 section。
schema 欄位應使用合適型別、易懂名稱和合理預設值。每個 block 也要處理空資料、文字過長、圖片缺少與行動版排序。只有編輯器能新增成功，還沒有完成客製。
第三層：用 metafield 與 metaobject 接資料
商品規格、材質、尺寸、FAQ 或品牌人物若會在多個頁面重用，可由 metafield 或 metaobject 管理，再透過 dynamic source 接到 section。這能減少複製貼上，也讓資料和版型分開。
欄位建立前要定義語意、型別、是否必填、擁有者和移除方式。臨時新增一批名稱相近的 metafield，幾個月後很難知道哪個仍在前台使用。
第四層：必要時才改 Liquid 與 JavaScript
自訂促銷顯示、變體互動或特殊商品流程可能需要 Liquid 和 JavaScript。程式應放在版本控制，使用 Shopify CLI 或團隊既定流程發布，不要只在 production code editor 直接修改。每次變更附上需求、影響 template 和測試案例，才能在更新 Theme 時辨認差異。
JavaScript 應以 progressive enhancement 為原則。商品資訊和主要購買流程若完全依賴大型前端套件，載入失敗時會直接阻斷交易，也增加效能成本。
App 功能優先使用 Theme App Extension
第三方或自訂 App 若要在 storefront 顯示內容，優先確認是否提供 app block 或 app embed。Theme App Extension 讓 App 在受控位置提供模組，商家能在 editor 管理，移除 App 時也較不容易留下手動貼入的程式碼。
若供應商要求修改 theme.liquid 或複製 snippet，記錄每個檔案和移除步驟。更新 Theme 前先在副本驗證，不要把未知程式直接搬到新版。
客製完成要留下更新路徑
驗收涵蓋桌面與手機、鍵盤、不同商品狀態、內容長度、App 共存、效能和 Theme editor。再建立客製清單：檔案、目的、資料依賴、owner、測試方式與新版 Theme 的處理方案。
正式發布前，讓實際內容編輯者新增一個 section、替換 dynamic source、複製 template 並復原錯誤設定。工程畫面正確之外，營運者也要能在不進入程式碼的情況下完成日常任務，才算客製交付完成。
改動很小時，維持接近原 Theme 的架構最省事；差異逐漸擴大時，應把重複的樣式和元件整理成設計系統，而非繼續疊 patch。可先看 Shopify 佈景主題選擇指南，確認問題來自 Theme 選擇還是客製執行，再決定投入範圍。