1.3 產品 Catalog 點拎 Data？

Frontend 唔會將產品資料 Build 入 Bundle 入面，而係靠 API 拎：

• GET /api/products?limit=500&active=1：一次過拎晒所有活躍產品。
• GET /api/products?q=...：搜尋。
• GET /api/products/<slug>：拎單一產品詳情。
• GET /api/products/categories：拎分類。

呢個做法嘅好處係：改產品價錢、庫存嘅時候，唔使重新 Build Frontend，Database 改完 Frontend 就見得到。

但係都有問題：

• limit=500 係一個危險信號。如果得十幾個產品，一次過 Load 晒冇問題；但如果有幾千個 SKU，呢個 Request 嘅 Payload 會好大，Query Time 會好長，浪費頻寬同記憶體。長遠應該改用 Cursor Pagination 同 Field Projection。
• 個 Product Schema 有啲唔夠標準化。例如 stock 喺 Product Level，但同時又有 variants；sizes、colors 呢啲 Option Strings 又唔統一（有 XXL 又有 2XL，有 ink navy 又有 Ink Navy）。咁樣會令 Filter、Analytics 同埋 Inventory Management 好易出錯。改進方向係將 SKU 同 Inventory 歸落 Variant Level。

1.4 Homepage 係點砌出嚟？

個 Homepage 係由 section_order 控制嘅 Block Composition。即係話，Marketing Team 可以喺 CMS 後面改次序、開關某啲 Section（Hero Banner、Product Grid、Promo Bar 等），而唔使 Frontend Developer 改 Code。

好處： 好 flexible，Marketing 可以自己玩。

壞處： 現有系統入面有啲 Key 唔統一，例如同時出現 ann 同 announcement，可能會令 CMS Configuration 同 Frontend Component 之間對唔齊，導致某啲 Block Render 唔到或者顯示錯咗。新系統應該用一個統一嘅 Block List，每個 Block 都有自己嘅 id、kind、enabled、position、payload，咁就唔會亂。

1.5 Layout 同 Settings

/api/layout 控制 Header、Footer、Navigation 呢啲全站通用嘅元素，而 /api/public/settings 就放 Branding、Logo、Social Links、Payment Methods、運費設定呢啲 Store Configuration。

好處： 將呢啲設定放喺 API，等 Frontend 可以動態更新，唔使靠 Config File 或者 Env Variable。

壞處： 呢個 Public Settings API 會一次過 Return 晒所有資料，包括 tax_id、公司地址、營運 Email 呢啲未必需要公開嘅資料。另外，呢類 Key-Value Store 冇 Type Checking，好易入錯 Data Type（例如 paypal_sandbox 入咗個字串 "true" 或者 1）。新系統應該將 Public Settings 同 Internal/Secret Settings 分開存放。

1.6 Coupon 同 PayPal Checkout 嘅流程推斷

一個比較穩陣嘅 Checkout 流程應該係咁：

1. Browser 將購物車同 Coupon Code 傳俾 Server。
2. Server 從 Database 重新拎產品同 Variant 嘅最新資料（價錢、庫存、優惠）。
3. Server 自己計 Subtotal、Discount、Shipping、Tax 同 Total。Server 絕對唔可以信 Browser 傳嚟嘅價錢。
4. Server Call POST /api/paypal/create-order，用 Server-side Credential 去 PayPal 開一個 Order，然後將 Order ID 傳返俾 Browser。
5. Browser 打開 PayPal Popup，等用戶 Approve。
6. 用戶 Approve 之後，Browser Call POST /api/paypal/capture。
7. Server Capture 個 Order，核對金額同貨幣，成功後就 Create 正式 Order、扣庫存、記錄 Payment Attempt。
8. 同時要用 PayPal Webhook 做核對，防止網絡問題導致 Capture 成功但網站收唔到通知。

而家有咩潛在風險？

• Idempotency（冪等性）： 如果用戶 Double Click，或者 Network Retry，會唔會 Create 或者 Capture 咗兩次 Order？需要有 Idempotency Key。
• Transaction / Locking： 扣庫存嘅時候，點防止 Oversell？要用 Database Transaction 或者 Lock。
• State Machine： Checkout 流程需要一個清晰嘅狀態機（例如：Cart -> Pending -> Approved -> Captured -> Completed），確保每一步都係確定嘅。

1.7 Review、Newsletter、Contact、Tracking

呢啲功能令呢個 Backend 唔止係一個 Catalog API，而係一個完整嘅 Commerce Application。

• Review： 需要 Pending / Approved / Rejected 狀態機、Spam Protection、Rate Limit，同埋如果要有「Verified Purchase」標籤，就要核對用戶係咪真係買過。
• Newsletter： 需要 Email Normalization、Unique Constraint、Double Opt-in 機制（視乎地區法例）、同埋 Unsubscribe 功能。唔好將 Email 就咁 Log 喺 Plaintext。
• Contact： 一定要有 CAPTCHA 或者 Bot Protection、Rate Limit，同埋用 Queue 去 Send Email，唔好等 Email Provider 做 Sync Response。
• Order Tracking： 唔好用一個好短、好易估嘅 Order Number 俾人 Check，例如 Order #123。應該要用 Signed Token 或者 Email + Order Reference 嘅組合，再加 Rate Limit，防止被人 Enumeration 偷睇人哋嘅訂單資料。

1.8 Analytics / Tracking

POST /api/track 呢個 Endpoint 可能會收集 Page View、Campaign 或者 Commerce Event。好處係可以避開 Ad Blocker，壞處係如果乜嘢 Event 都收、乜嘢 Data 都 Save，好快會搞到 DB 好大，仲有 Privacy 問題。應該要用 Whitelist 嘅 Event Schema、限制 Payload Size、Hash 或者 Drop PII，同埋用 Queue 去做非同步處理。

二、同 WooCommerce 逐項比較

2.1 咁樣係咪仲「叻」過 WooCommerce？

用 React 同 Custom API 唔代表就一定好。Custom 畀到你更高嘅 Control，但同時你都要承擔所有開發同維護嘅責任。效能、SEO、安全呢啲嘢，唔係用咗個「靚」Framework 就自動搞掂，而係取決於你點 Design 個 Data Model、點做 Rendering、點做 Cache、點做 Testing。

2.2 速度 Loading Speed

結論： Custom 嘅潛在效能天花板係高啲（如果有做 SSR/SSG 同 Optimize），但 WooCommerce 嘅 Baseline 相對簡單易控制。唔好齋講用咩 Tech Stack，要睇 Real User Monitoring 嘅 Core Web Vitals（LCP、FID/INP、CLS）先係真。

2.3 SEO

呢個係最關鍵嘅分野。

WooCommerce 傳統： 預設就係 Server-side Rendering，HTML 入面有齊晒 Product Name、Description、Metadata，Googlebot 一嚟到就睇到晒，唔使等 JS。

Custom CSR SPA： 係 Google 嘅眼中，佢一開始只係見到一個 Empty Div。雖然 Google 識行 JS，但係有幾個風險：

1. 索引延遲： 新頁面或者更新咗嘅內容，要等 Google 行完 JS 先至見到，呢個過程可能係幾個鐘甚至幾日。
2. Soft 404： 如果一個唔存在嘅 URL（例如 /product/not-exist）因為 Catch-all Route 而 Return 200 OK，然後靠 React 喺 Client Side 顯示「404」，Google 可能會當呢個係 Soft 404，影響網站整體評分。
3. Metadata 更新唔及時： Title、Description、Canonical URL、Open Graph 呢啲嘢，如果係 Client Side 用 JS 改，Social Crawler（例如 Facebook、Twitter）可能睇唔到，Share Link 嘅時候會冇預覽圖同描述。
4. API 問題： 如果 Googlebot 嚟嘅時候個 API 慢咗或者出錯，佢就會見到一個空白頁，認為呢個頁面冇內容，唔會 Index。

Google 官方建議： 佢哋已經明確表示 Dynamic Rendering（對 Bot 俾 Pre-rendered HTML，對 User 俾 SPA）只係一個 Workaround，唔係長期解決方案。最佳做法係用 Server-Side Rendering (SSR)、Static Site Generation (SSG) 或者 Incremental Static Regeneration (ISR)。

2.4 維護同成本

2.5 擴展性

Custom 嘅架構可以將 Frontend 同 Backend 獨立 Scale，CDN、API Workers、Database 可以各自加 Machine。不過，Scaling 嘅真正難題永遠係 Database Transaction、Inventory Reservation 同 Payment Idempotency，呢啲係 Architecture 問題，唔係加 Machine 搞得掂。WooCommerce 用 Managed Hosting 同好好嘅 Cache Strategy，亦可以應付可觀嘅 Traffic。

三、如果轉 Source Code，應該點樣寫？

3.1 核心原則：唔係抄，係重新實作 Business Logic

可以保留嘅係 Business Logic 同 Domain Knowledge（例如：產品有 Category、Homepage 有 Block、Checkout 有 Coupon 同 PayPal），但係要用全新、標準化、符合現代標準嘅架構去實作。唔可以抄現有 Bundle 入面嘅 Private Variable Name 或者 Module Structure。

3.2 建議嘅 Tech Stack

Frontend: Next.js App Router + React + TypeScript

• 點解揀 Next.js？ 因為佢支援 Server Components、SSR、SSG、ISR，可以將大部分頁面（產品頁、分類頁、Homepage）預先 Render 成 HTML，解決 SEO 同 First Load 慢嘅問題。只有 Shopping Cart、User Dashboard 呢啲需要 Client Side 互動嘅部分先用 Client Components。
• Validation： 用 Zod 喺 API Boundary 做 Type Checking。
• Data Fetching： 用 TanStack Query 去處理需要 Client Side Refresh 嘅資料，但 唔好將已經喺 Server 度 Render 好嘅 Data 再 Fetch 多次。
• Image Optimization： 用 CDN（例如 Cloudflare Images 或者 imgix）去做 On-the-fly Resize 同 WebP/AVIF Conversion，減輕 Frontend Server 負擔。

Backend: NestJS (Fastify Adapter) + PostgreSQL

• 點解揀 NestJS？ 佢提供一個有架構、模塊化嘅 TypeScript Backend Framework，好適合處理複雜嘅 E-commerce Logic。Fastify Adapter 比 Express 快。
• Database： PostgreSQL 做 Source of Truth，用 Drizzle ORM 或者 Prisma 做 Migration 同 Type-safe Query。
• Cache： Redis 唔使一開始就用，除非你真係需要做 Distributed Lock 或者 High-throughput Cache。
• Queue： BullMQ 或者類似嘅 Queue System 用嚟處理 Email、Webhook Retry、Analytics Ingestion，確保系統 Responsive。
• Media： 用 S3-compatible Object Storage（例如 AWS S3、Cloudflare R2），Database 只儲 URL 同 Metadata。
• Observability： 用 OpenTelemetry + Structured Logging + Error Tracking（例如 Sentry），方便 Debug 同 Tracing。

3.3 針對 SEO 嘅改善方案

1. SSR / ISR： 產品頁、分類頁、Homepage 同 Content Page 一定要用 SSR 或者 ISR，確保第一次 Request 就 Return 齊 HTML。
2. 正確嘅 HTTP Status Code： 如果一個產品唔存在，Server 要 Return 404 Not Found，唔好全部 Return 200 OK。
3. Server-side Metadata： Title、Description、Canonical URL、JSON-LD Structured Data (Product, Breadcrumb, Organization) 全部喺 Server Side Generate，唔好靠 Client Side JS 改。
4. Internal Links： 確保所有導航連結係 <a href="..."> 呢種 Crawlable 嘅 Link，唔好用 onClick handler 去處理。
5. XML Sitemap： 動態 Generate Sitemap，確保 Google 發現所有新產品同分類。
6. Pagination / Filter： 確保 Filter 同 Pagination 嘅 URL 係 Canonical 嘅，唔好製造無限嘅 Duplicate Content。

總結：下一步應該點行？

如果目標係 快啲開到鋪、團隊細、商業流程標準，用 WooCommerce 配一個輕 Theme 同少 Plugin 係穩陣嘅選擇。

如果目標係 要完整嘅 Brand Experience、自己有 Developer Team、長遠想控製成個 Tech Stack，咁 Custom 方向係啱嘅，但係一定要升級做 SSR/ISR Hybrid Rendering，唔好再停留喺純 CSR 嘅階段。

最關鍵嘅建議： 唔好因為「聽落 Pro」就揀 Custom，亦唔好因為「怕煩」就揀 WooCommerce。要睇你嘅 Business Requirement、Team Capability、同埋長遠 Roadmap。

呢篇文章嘅分析係基於觀察到嘅 Frontend 同 API Behavior，Backend 嘅實際 Language 同 Framework 係要睇更多資訊（例如 Response Headers、Error Format、Deployment Config）先可以確定，現階段唔應該胡亂猜測。

1.3 產品 Catalog 點拎 Data？

Frontend 唔會將產品資料 Build 入 Bundle 入面，而係靠 API 拎：

• GET /api/products?limit=500&active=1：一次過拎晒所有活躍產品。
• GET /api/products?q=...：搜尋。
• GET /api/products/<slug>：拎單一產品詳情。
• GET /api/products/categories：拎分類。

呢個做法嘅好處係：改產品價錢、庫存嘅時候，唔使重新 Build Frontend，Database 改完 Frontend 就見得到。

但係都有問題：

• limit=500 係一個危險信號。如果得十幾個產品，一次過 Load 晒冇問題；但如果有幾千個 SKU，呢個 Request 嘅 Payload 會好大，Query Time 會好長，浪費頻寬同記憶體。長遠應該改用 Cursor Pagination 同 Field Projection。
• 個 Product Schema 有啲唔夠標準化。例如 stock 喺 Product Level，但同時又有 variants；sizes、colors 呢啲 Option Strings 又唔統一（有 XXL 又有 2XL，有 ink navy 又有 Ink Navy）。咁樣會令 Filter、Analytics 同埋 Inventory Management 好易出錯。改進方向係將 SKU 同 Inventory 歸落 Variant Level。

1.4 Homepage 係點砌出嚟？

個 Homepage 係由 section_order 控制嘅 Block Composition。即係話，Marketing Team 可以喺 CMS 後面改次序、開關某啲 Section（Hero Banner、Product Grid、Promo Bar 等），而唔使 Frontend Developer 改 Code。

好處： 好 flexible，Marketing 可以自己玩。

壞處： 現有系統入面有啲 Key 唔統一，例如同時出現 ann 同 announcement，可能會令 CMS Configuration 同 Frontend Component 之間對唔齊，導致某啲 Block Render 唔到或者顯示錯咗。新系統應該用一個統一嘅 Block List，每個 Block 都有自己嘅 id、kind、enabled、position、payload，咁就唔會亂。

1.5 Layout 同 Settings

/api/layout 控制 Header、Footer、Navigation 呢啲全站通用嘅元素，而 /api/public/settings 就放 Branding、Logo、Social Links、Payment Methods、運費設定呢啲 Store Configuration。

好處： 將呢啲設定放喺 API，等 Frontend 可以動態更新，唔使靠 Config File 或者 Env Variable。

壞處： 呢個 Public Settings API 會一次過 Return 晒所有資料，包括 tax_id、公司地址、營運 Email 呢啲未必需要公開嘅資料。另外，呢類 Key-Value Store 冇 Type Checking，好易入錯 Data Type（例如 paypal_sandbox 入咗個字串 "true" 或者 1）。新系統應該將 Public Settings 同 Internal/Secret Settings 分開存放。

1.6 Coupon 同 PayPal Checkout 嘅流程推斷

一個比較穩陣嘅 Checkout 流程應該係咁：

1. Browser 將購物車同 Coupon Code 傳俾 Server。
2. Server 從 Database 重新拎產品同 Variant 嘅最新資料（價錢、庫存、優惠）。
3. Server 自己計 Subtotal、Discount、Shipping、Tax 同 Total。Server 絕對唔可以信 Browser 傳嚟嘅價錢。
4. Server Call POST /api/paypal/create-order，用 Server-side Credential 去 PayPal 開一個 Order，然後將 Order ID 傳返俾 Browser。
5. Browser 打開 PayPal Popup，等用戶 Approve。
6. 用戶 Approve 之後，Browser Call POST /api/paypal/capture。
7. Server Capture 個 Order，核對金額同貨幣，成功後就 Create 正式 Order、扣庫存、記錄 Payment Attempt。
8. 同時要用 PayPal Webhook 做核對，防止網絡問題導致 Capture 成功但網站收唔到通知。

而家有咩潛在風險？

• Idempotency（冪等性）： 如果用戶 Double Click，或者 Network Retry，會唔會 Create 或者 Capture 咗兩次 Order？需要有 Idempotency Key。
• Transaction / Locking： 扣庫存嘅時候，點防止 Oversell？要用 Database Transaction 或者 Lock。
• State Machine： Checkout 流程需要一個清晰嘅狀態機（例如：Cart -> Pending -> Approved -> Captured -> Completed），確保每一步都係確定嘅。

1.7 Review、Newsletter、Contact、Tracking

呢啲功能令呢個 Backend 唔止係一個 Catalog API，而係一個完整嘅 Commerce Application。

• Review： 需要 Pending / Approved / Rejected 狀態機、Spam Protection、Rate Limit，同埋如果要有「Verified Purchase」標籤，就要核對用戶係咪真係買過。
• Newsletter： 需要 Email Normalization、Unique Constraint、Double Opt-in 機制（視乎地區法例）、同埋 Unsubscribe 功能。唔好將 Email 就咁 Log 喺 Plaintext。
• Contact： 一定要有 CAPTCHA 或者 Bot Protection、Rate Limit，同埋用 Queue 去 Send Email，唔好等 Email Provider 做 Sync Response。
• Order Tracking： 唔好用一個好短、好易估嘅 Order Number 俾人 Check，例如 Order #123。應該要用 Signed Token 或者 Email + Order Reference 嘅組合，再加 Rate Limit，防止被人 Enumeration 偷睇人哋嘅訂單資料。

1.8 Analytics / Tracking

POST /api/track 呢個 Endpoint 可能會收集 Page View、Campaign 或者 Commerce Event。好處係可以避開 Ad Blocker，壞處係如果乜嘢 Event 都收、乜嘢 Data 都 Save，好快會搞到 DB 好大，仲有 Privacy 問題。應該要用 Whitelist 嘅 Event Schema、限制 Payload Size、Hash 或者 Drop PII，同埋用 Queue 去做非同步處理。

二、同 WooCommerce 逐項比較

2.1 咁樣係咪仲「叻」過 WooCommerce？

用 React 同 Custom API 唔代表就一定好。Custom 畀到你更高嘅 Control，但同時你都要承擔所有開發同維護嘅責任。效能、SEO、安全呢啲嘢，唔係用咗個「靚」Framework 就自動搞掂，而係取決於你點 Design 個 Data Model、點做 Rendering、點做 Cache、點做 Testing。

2.2 速度 Loading Speed

結論： Custom 嘅潛在效能天花板係高啲（如果有做 SSR/SSG 同 Optimize），但 WooCommerce 嘅 Baseline 相對簡單易控制。唔好齋講用咩 Tech Stack，要睇 Real User Monitoring 嘅 Core Web Vitals（LCP、FID/INP、CLS）先係真。

2.3 SEO

呢個係最關鍵嘅分野。

WooCommerce 傳統： 預設就係 Server-side Rendering，HTML 入面有齊晒 Product Name、Description、Metadata，Googlebot 一嚟到就睇到晒，唔使等 JS。

Custom CSR SPA： 係 Google 嘅眼中，佢一開始只係見到一個 Empty Div。雖然 Google 識行 JS，但係有幾個風險：

1. 索引延遲： 新頁面或者更新咗嘅內容，要等 Google 行完 JS 先至見到，呢個過程可能係幾個鐘甚至幾日。
2. Soft 404： 如果一個唔存在嘅 URL（例如 /product/not-exist）因為 Catch-all Route 而 Return 200 OK，然後靠 React 喺 Client Side 顯示「404」，Google 可能會當呢個係 Soft 404，影響網站整體評分。
3. Metadata 更新唔及時： Title、Description、Canonical URL、Open Graph 呢啲嘢，如果係 Client Side 用 JS 改，Social Crawler（例如 Facebook、Twitter）可能睇唔到，Share Link 嘅時候會冇預覽圖同描述。
4. API 問題： 如果 Googlebot 嚟嘅時候個 API 慢咗或者出錯，佢就會見到一個空白頁，認為呢個頁面冇內容，唔會 Index。

Google 官方建議： 佢哋已經明確表示 Dynamic Rendering（對 Bot 俾 Pre-rendered HTML，對 User 俾 SPA）只係一個 Workaround，唔係長期解決方案。最佳做法係用 Server-Side Rendering (SSR)、Static Site Generation (SSG) 或者 Incremental Static Regeneration (ISR)。

2.4 維護同成本

2.5 擴展性

Custom 嘅架構可以將 Frontend 同 Backend 獨立 Scale，CDN、API Workers、Database 可以各自加 Machine。不過，Scaling 嘅真正難題永遠係 Database Transaction、Inventory Reservation 同 Payment Idempotency，呢啲係 Architecture 問題，唔係加 Machine 搞得掂。WooCommerce 用 Managed Hosting 同好好嘅 Cache Strategy，亦可以應付可觀嘅 Traffic。

三、如果轉 Source Code，應該點樣寫？

3.1 核心原則：唔係抄，係重新實作 Business Logic

可以保留嘅係 Business Logic 同 Domain Knowledge（例如：產品有 Category、Homepage 有 Block、Checkout 有 Coupon 同 PayPal），但係要用全新、標準化、符合現代標準嘅架構去實作。唔可以抄現有 Bundle 入面嘅 Private Variable Name 或者 Module Structure。

3.2 建議嘅 Tech Stack

Frontend: Next.js App Router + React + TypeScript

• 點解揀 Next.js？ 因為佢支援 Server Components、SSR、SSG、ISR，可以將大部分頁面（產品頁、分類頁、Homepage）預先 Render 成 HTML，解決 SEO 同 First Load 慢嘅問題。只有 Shopping Cart、User Dashboard 呢啲需要 Client Side 互動嘅部分先用 Client Components。
• Validation： 用 Zod 喺 API Boundary 做 Type Checking。
• Data Fetching： 用 TanStack Query 去處理需要 Client Side Refresh 嘅資料，但 唔好將已經喺 Server 度 Render 好嘅 Data 再 Fetch 多次。
• Image Optimization： 用 CDN（例如 Cloudflare Images 或者 imgix）去做 On-the-fly Resize 同 WebP/AVIF Conversion，減輕 Frontend Server 負擔。

Backend: NestJS (Fastify Adapter) + PostgreSQL

• 點解揀 NestJS？ 佢提供一個有架構、模塊化嘅 TypeScript Backend Framework，好適合處理複雜嘅 E-commerce Logic。Fastify Adapter 比 Express 快。
• Database： PostgreSQL 做 Source of Truth，用 Drizzle ORM 或者 Prisma 做 Migration 同 Type-safe Query。
• Cache： Redis 唔使一開始就用，除非你真係需要做 Distributed Lock 或者 High-throughput Cache。
• Queue： BullMQ 或者類似嘅 Queue System 用嚟處理 Email、Webhook Retry、Analytics Ingestion，確保系統 Responsive。
• Media： 用 S3-compatible Object Storage（例如 AWS S3、Cloudflare R2），Database 只儲 URL 同 Metadata。
• Observability： 用 OpenTelemetry + Structured Logging + Error Tracking（例如 Sentry），方便 Debug 同 Tracing。

3.3 針對 SEO 嘅改善方案

1. SSR / ISR： 產品頁、分類頁、Homepage 同 Content Page 一定要用 SSR 或者 ISR，確保第一次 Request 就 Return 齊 HTML。
2. 正確嘅 HTTP Status Code： 如果一個產品唔存在，Server 要 Return 404 Not Found，唔好全部 Return 200 OK。
3. Server-side Metadata： Title、Description、Canonical URL、JSON-LD Structured Data (Product, Breadcrumb, Organization) 全部喺 Server Side Generate，唔好靠 Client Side JS 改。
4. Internal Links： 確保所有導航連結係 <a href="..."> 呢種 Crawlable 嘅 Link，唔好用 onClick handler 去處理。
5. XML Sitemap： 動態 Generate Sitemap，確保 Google 發現所有新產品同分類。
6. Pagination / Filter： 確保 Filter 同 Pagination 嘅 URL 係 Canonical 嘅，唔好製造無限嘅 Duplicate Content。

總結：下一步應該點行？

如果目標係 快啲開到鋪、團隊細、商業流程標準，用 WooCommerce 配一個輕 Theme 同少 Plugin 係穩陣嘅選擇。

如果目標係 要完整嘅 Brand Experience、自己有 Developer Team、長遠想控製成個 Tech Stack，咁 Custom 方向係啱嘅，但係一定要升級做 SSR/ISR Hybrid Rendering，唔好再停留喺純 CSR 嘅階段。

最關鍵嘅建議： 唔好因為「聽落 Pro」就揀 Custom，亦唔好因為「怕煩」就揀 WooCommerce。要睇你嘅 Business Requirement、Team Capability、同埋長遠 Roadmap。

呢篇文章嘅分析係基於觀察到嘅 Frontend 同 API Behavior，Backend 嘅實際 Language 同 Framework 係要睇更多資訊（例如 Response Headers、Error Format、Deployment Config）先可以確定，現階段唔應該胡亂猜測。