商城小程式客製開發怎麼選：先看資料、原始碼和年費，再看功能表
一份商城小程式的功能清單，在模板商、SaaS 服務商和純客製團隊手裡能報出差一個數量級的價格，三份報價還都能把同一批選項勾滿。差別不在功能，在邊界。
功能表比價失效的原因很樸素：三條路線的成本結構不一樣。模板是把做好的成品改皮，功能早就攤在幾百個客戶身上，邊際成本接近零；SaaS 把開發和維運攤進年費和插件費，你買的是使用權；客製從零算人天，需求梳理、原型、開發、測試每一步都要人。用一張勾選表去比，比的是三種計價方式，不是三種產品。
模板套改能改什麼
配色、首頁模組順序、兩三個靜態頁、部分文案，這些都沒問題。不能動的是欄位模型。多數成品商城的商品表是固定結構，單規格或者最多兩層，促銷只有滿減和優惠券。要加「多規格 + 預售 + 兩級分銷」，已經動到資料庫和訂單狀態機，服務商要嘛直接拒絕，要嘛把價格報到客製區間。判斷模板夠不夠，不看頁面像不像，看你的業務能不能塞進它的欄位。
SaaS 建站的邊界在資料放在誰那裡
能開什麼功能由產品路線圖決定，你提的需求進排期池，不承諾日期。資料在服務商的資料庫裡，通常給報表匯出，不給整庫。年費之外還有插件費、交易費率、超出套餐的簡訊與儲存費用。它適合 SKU 少、規則簡單、沒有既有系統要對接的標準化零售。如果商城要跟 ERP 或線下門店庫存打通，先確認對方有沒有開放介面，沒有就到此為止，別指望上線後再補。
純客製的代價在前段
需求要一條條梳理，原型要簽字，測試要有人跟，工期以月計。雨果網 10 月那篇比較獨立站開發渠道的文章給的量級是客製開發數萬元起、週期至少一個月，這是量級參考，不是報價。網易號 11 月的服務商盤點列出的三類投訴是模板套改、交付延期、售後無人回應，正好對應上面幾條邊界被越過之後的結果。
四步判斷，每一步都有問句
第一步問業務複雜度，三個問句就夠：商品變體維度是不是超過兩個（顏色 + 尺碼 + 套餐）；促銷是否需要規則疊加、互斥和優先級；要不要對接既有的 ERP、倉儲或門店庫存。命中兩個以上，模板路線基本走不通，因為每一條都會改到資料結構。
第二步問資料歸屬：使用者手機號碼、訂單、支付流水、行為日誌存在誰的資料庫裡；能不能整庫匯出而不是匯出報表；匯出頻率和欄位範圍；服務商停服、漲價或被併購時，退出路徑是什麼。答不上來，等於把客戶資產託管在別人的商業決策上。這不是技術問題。
第三步算三年總成本。客製是一次性開發費加年維護費；SaaS 是年費加插件加交易費率加可能的二次開發費用；模板二開看著最便宜，但原廠升級會覆蓋你的改動，第二次升級要嘛放棄改動，要嘛再付一次錢。三年帳放進同一張表，很多「便宜一半」的報價會翻過來。
第四步看交付週期和上線窗口對不對得上。外貿旺季前兩個月、平台大促前一個月都不是適合上線的窗口。客製可以按里程碑分批上線，SaaS 上線快但能力受限，模板最快、改動空間最小。順帶把備案與主體認證的排期算進工期，小程式備案、網域備案、支付商戶號開通這幾項卡住的時間，經常比開發本身還長。
還有一動常被忽略：讓對方做一次小樣本試改。給兩個真實需求，比如「加一個組合套餐欄位」和「把商品詳情拆成中英兩套」，讓每條路線各自報改動範圍。模板和 SaaS 的回答通常在這兩個需求上分岔，一小時內就能看清邊界在哪。
多語言要拆成三層看，它不是一項功能
報價單裡的「支援多語言」至少有三種含義，混在一起談，後面必然扯不清。
第一層是介面文案：按鈕、提示語、錯誤碼。做法是把文案抽成 key 加語言包，頁面只引用 key。第二層是內容資料：商品標題、詳情富文本、類目名稱、SEO 描述，需要後台按欄位存多語言，而不是給整站套一層翻譯。第三層是交易鏈路：貨幣、價格展示、地址格式、發票與稅號、支付通道、客服話術和時區。三層裡只有第一層是翻譯工作，後兩層是資料模型和結算設計，改起來貴得多。
小程式的實際情況要認清：官方沒有內建的多語言框架，語言包得自己建，語言從系統資訊取得，同時要給使用者手動切換的入口並記住選擇。切換之後登入狀態、購物車、優惠券不能丟——這些狀態如果只掛在中文文案的頁面上，切換就是一次無聲清空。文案寫死在頁面裡是後期返工最大的來源，改一個按鈕要動幾十個檔案再重新送審，第二次加語種的工期往往比第一次還長。
外貿獨立站那一側有另一套動作。每個語言版本要有獨立、能被抓取的 URL，主流做法是子目錄 /en/、/de/，權重繼承自然、一套程式碼維護；不建議 ?lang=en 這類參數 URL。hreflang 要互鏈，每個頁面包含指向自己的那一條，還要有 x-default。Google 的文件明確不建議按 IP 或瀏覽器語言自動跳轉，爬蟲多數不帶地區語言訊號，一跳轉小語種版本就抓不到。選型階段問清楚：模板或 SaaS 是支援子目錄多語言，還是只能靠插件拼；hreflang 是自動輸出還是要手工維護。
粗略的判斷口徑：語種數兩個以上且商品標題、詳情要本地化，模板基本不夠用；只有介面多語言、商品內容統一英文，SaaS 插件可能夠；面向多國還要按市場定價、算稅、走不同支付通道，走客製，或者客製加現成商城框架。
報價單和合約
報價單怎麼讀，能看出後面會不會追加。看它是否把需求梳理、視覺設計、前端、後端、測試、部署、語言包、上架與備案代辦、首年維護分開列。混成一句「總價 XX 萬」的，這幾項裡任何一項都可能在最急的時候變成追加項。分得越細，說明對方真的做過商城專案。
還有一件常被漏算的東西：翻譯與審校的責任。語言包裡的 key 誰翻、誰審、改版後多久同步到各語種，沒約定的話，多語言版本會在每次改版後落後兩三週。把它寫進維護範圍，或者明確按字計費。
合約上我一般堅持四條：
- 原始碼和文件寫成交付物，掛在尾款驗收之前；
- 智慧財產權歸屬與第三方元件授權清單附上，避免用了收費元件才發現要額外授權；
- 資料歸屬寫清楚，包括合約終止時的匯出義務和格式；
- 逾期與驗收不通過的處置口徑寫具體，按日賠付有上限，驗收不通過有重做時限。
四條都不複雜，難的是簽的時候堅持。
我們做純客製時，報價會把原始碼、部署文件和多語言語言包一起列成交付項，逾期按合約賠付，上線後給 3 個月免費維護期。合約裡寫清楚的東西，比口頭承諾有用。
如果只能帶走一句：把三年總成本和你計畫涵蓋的語種數、市場數寫在同一個表裡，再坐下來談價。至於第三年要加第三個語種時這套東西還能不能改，答案在第一次簽合約時就定了。