Sanity 和 Shopify 都能保存內容，若沒有資料邊界，同一商品名稱、圖片或敘述可能在兩邊各有版本。前端不知道該信哪一份，內容團隊也會重複更新。分工原則是讓交易事實留在 Shopify，敘事與編輯關係由 Sanity 管理，再用穩定 reference 連接。
這條原則仍需逐欄位確認，不能只把「商品」整包歸給某一系統。
Shopify 保存交易事實
Product、variant、SKU、price、compare-at price、availability、selling plan、collection、cart 和 checkout 由 Shopify 提供。這些資料會直接影響可售與付款，前端應在需要的 market 和 buyer context 讀取，不從 CMS 複製一份可能過期的價格。
商品基本標題與主要媒體若由商品團隊在 Shopify 維護，也可作為交易目錄的一部分。若 PIM 才是來源，則需另行畫出 PIM 到 Shopify 的同步責任。
Sanity 保存敘事與內容關係
品牌故事、editorial、campaign、buying guide、作者、FAQ、landing page modules 和跨內容 reference 適合在 Sanity 建模。內容團隊可依語意重用模組、安排市場版本與發布，而不用把長篇內容塞入商品欄位。
模型名稱應描述內容角色，例如 buyingGuide 或 materialStory，不要使用 leftColumnBlock 等版面名稱。前端改版後，內容仍能保留意義。
使用穩定商品 reference
Sanity document 若要連 Shopify 商品，保存穩定 identifier，例如 Shopify GraphQL global ID 或經治理的 handle，並記錄 market 可見性。Handle 可能因 SEO 改名，若被當唯一關聯鍵，內容 reference 可能失效。
可建立 reference resolver，在預覽和發布時檢查商品存在、已發布到對應 channel 且可售。CMS 中不需要複製完整商品 object，只保存編輯所需的摘要與識別。
前端組合時定義 fallback
頁面 query 可能同時讀 Sanity 和 Storefront API。先決定哪一方失敗時的行為：CMS 暫時無法回應，可否用快取內容；商品不存在時，是否隱藏推薦卡或阻擋整頁；價格不可用時，不能繼續顯示舊數字。
建立 typed view model 將兩邊資料合併，元件不直接猜不同 API 形狀。Log 應能追到 Sanity document ID、Shopify product ID 和 request trace。
預覽需要草稿與真實商品
Sanity 的 visual editing 可透過 Content Source Maps、draft perspective 和 preview frontend 顯示草稿。預覽頁同時讀取 Shopify 真實或測試商品，並清楚標示環境。Draft token 只留在受保護 server session，production query 使用公開 perspective 和適當 CDN/cache。
Slug、locale 和 market resolver 必須讓編輯者到正確頁面。新 document 尚未發布時也要有 preview URL，不要求先建立公開空頁。
發布與 cache 失效分開處理
Sanity publish webhook 可觸發前端 revalidation；Shopify product webhook 則更新商品相關 cache 或搜尋 index。事件可能重送，handler 要 idempotent。一次內容更新只失效相關頁面，避免每次改字都清除全站 cache。
若兩邊需要 coordinated release，例如 campaign 必須等商品上架，再建立發布檢查與營運 runbook。不要假設兩個後台按鈕會同時完成。
最後製作欄位級 ownership 表：名稱、來源、可編輯者、同步方向、前端用途、cache 和失敗行為。每季檢查重複資料和 orphan reference。可從 Headless CMS 選擇指南確認編輯需求，再用 Sanity CMS 服務評估實作與維運責任。