資料模型問題更嚴重：

• 庫存（stock）欄位存在於商品層級（product），但同時又有 variants（規格）陣列。真正的庫存管理應該以「SKU」（例如「黑色 / M 號」這個組合）為單位。
• 選項值未標準化：同時出現了 XXL 和 2XL，以及 ink navy 和 Ink Navy，這會導致資料過濾、分析功能無法穩定運作。
• 部分欄位（如 type, isbn）看起來像是從其他領域挪用，缺乏明確的電商語意。

1.3 首頁建構器（Homepage Builder）的設計

/api/homepage API 回傳包含 section_order 的設定，讓行銷人員可以透過後台排序、開關頁面上的區塊（如 Hero、產品展示）。這是個好設計，但問題在於一致性。

API 回傳中同時存在 ann 和 announcement（公告）兩個不同的 key，這表示資料結構可能經歷過不嚴謹的遷移。此外，區塊順序、開關狀態與實際資料是分開儲存的，容易產生不同步的 bug。重構時應將每個區塊整合成一個包含 id, kind, enabled, position, payload 的完整物件。

1.4 結帳流程與安全性（PayPal 整合）

結帳流程是標準的兩步驟：

1. 客戶端請求 POST /api/paypal/create-order，伺服器在後端創建 PayPal 訂單。
2. 客戶端驗證後，請求 POST /api/paypal/capture 完成交易。

至關重要的原則：伺服器絕不能信任客戶端傳來的價格、折扣或總金額。伺服器必須根據資料庫中的商品價格、折扣規則與運費設定，自行計算所有金額，否則極易被竄改。

報告也點出，良好與不良的實作差異，在於是否有做到：

• 冪等性金鑰 (Idempotency Key)：防止因網路問題重複點擊而導致重複扣款。
• 交易鎖 (Transaction/Locking)：防止超賣。
• Webhook 簽章驗證：確認付款通知確實來自 PayPal。

1.5 後端推測與安全提醒

雖然無法 100% 確定後端語言（可能是 Node.js、PHP 或 Python），但報告提出了一個關鍵的安全疑慮：/api/track 這類追蹤端點如果無條件接收所有請求資料，可能成為被濫用注入垃圾資料的管道，導致資料庫快速膨脹。

此外，/api/orders/track 允許用短數字序號查詢訂單，這存在列舉攻擊（enumeration attack）風險，可能洩露他人購買資訊。建議使用簽署的追蹤令牌（signed tracking token）或需要配對訂單號碼與電子郵件/ZIP 碼。

2. 正面對決：客製化 SPA vs. WooCommerce

2.1 SEO（搜尋引擎最佳化）

這是最關鍵的差距。

• WooCommerce 預設優勢：伺服器直接傳送包含產品 HTML 的頁面，Google 爬蟲一來就能讀取所有內容。
• 純客戶端渲染 SPA（現狀）：Google 雖然有能力執行 JavaScript，但它會延遲索引，而且依賴 API 的可用性。如果渲染引擎超時或 API 出錯，爬蟲看到的就是空白頁。

Google 官方文件已明確指出，動態渲染（Dynamic Rendering）只是權宜之計，不建議長期使用 。最佳解是 SSR（伺服器端渲染）或 SSG（靜態網站生成）。

更糟的是，這個網站目前採用的是「偽 SPA」架構：伺服器為所有路由回傳相同的、幾乎空白的 HTML。這對 Google 來說是「軟 404」與「內容稀少」的雙重打擊 。甚至連社交媒體爬蟲（如 Facebook、LINE 的連結預覽）都因為不執行 JavaScript，永遠抓不到正確的標題與圖片。

2.2 速度與效能

• 客製化 SPA 的潛力：在後續導航中因為僅需交換資料，理論上非常快。靜態資源可透過 CDN 極速傳遞。
• WooCommerce 的基礎：若搭配快取外掛、物件快取（如 Redis）與圖片優化，小型 WooCommerce 網站的首頁載入速度（FCP）可能遠勝過成熟的 SPA。

關鍵區別：SPA 的痛點在於首次載入。它必須先下載並執行大量 JavaScript，再打 API 取得資料，最後才渲染出商品圖片與價格，這段「載入空白」的時間對使用者體驗傷害極大。

2.3 維護與擴展

• WooCommerce：將網站改成產品上架、訂單管理的維護成本轉移到生態系維護（更新 WordPress 核心、外掛、主題，處理相容性問題）。
• 客製化系統：將維護成本轉移到工程團隊（維護前後端程式碼、API、資料庫遷移、CI/CD 流程）。沒有外掛市場，所有功能都得自己寫或整合。

對於一個 16 個商品的網站，客製化架構帶來的複雜度很可能遠超過其帶來的彈性優勢。

3. 重構建議：打造更具前瞻性的新程式碼庫

報告最終提出了一個務實的建議：繼續走客製化路線，但徹底翻新架構，而非直接改用 WooCommerce。因為該網站的頁面建構器與品牌體驗已是其核心競爭力。

3.1 具體建議

前端層（Storefront）

• 框架：採用 Next.js（App Router） 或 Remix 這類混合渲染框架。這能讓你對不同頁面採用不同策略：
  • 產品頁、行銷頁：使用 SSG（靜態生成）或 ISR（增量靜態再生），讓 HTML 一載入就有內容，SEO 與社群分享瞬間獲得改善。
  • 購物車抽屜、個人化推薦：仍可使用客戶端元件（Client Components）處理互動。
• 資料驗證：在 API 邊界使用 Zod 等工具做類型驗證。
• 圖片優化：利用 CDN/物件儲存服務的圖片處理功能，指定寬度與格式。

後端層

• 語言與框架：可考慮 NestJS 或 Fastify（TypeScript），並搭配 PostgreSQL。
• 資料庫工具：使用 Prisma 或 Drizzle ORM 來確保型別安全的資料庫操作與遷移。
• 佇列系統：引入 BullMQ 等任務佇列處理非同步作業，如發送電子郵件、處理 Webhook 重試與訂單對帳。這樣 HTTP 請求就不會直接阻塞在郵件伺服器上。
• 監控與可觀測性：導入 OpenTelemetry 進行分散式追蹤，串聯整個結帳流程，方便除錯。

3.2 決策表格

結論

這個網站並非使用 WooCommerce、Shopify 等現成平台，而是一個技術含量不低的客製化專案。然而，其純客戶端渲染的架構、不盡理想的資料模型，以及潛在的安全漏洞，為其 SEO、效能與穩定性帶來了顯著風險。

對於技術團隊而言，最務實的路線不是盲目改回 WooCommerce，而是借鏡這個客製化架構的優點（如頁面建構器），並用現代化的渲染模式（如 SSR/SSG）與更嚴謹的資料設計，從根本上解決問題。這份報告提供了一份詳盡的藍圖，供開發團隊作為評估與執行的參考。

資料模型問題更嚴重：

• 庫存（stock）欄位存在於商品層級（product），但同時又有 variants（規格）陣列。真正的庫存管理應該以「SKU」（例如「黑色 / M 號」這個組合）為單位。
• 選項值未標準化：同時出現了 XXL 和 2XL，以及 ink navy 和 Ink Navy，這會導致資料過濾、分析功能無法穩定運作。
• 部分欄位（如 type, isbn）看起來像是從其他領域挪用，缺乏明確的電商語意。

1.3 首頁建構器（Homepage Builder）的設計

/api/homepage API 回傳包含 section_order 的設定，讓行銷人員可以透過後台排序、開關頁面上的區塊（如 Hero、產品展示）。這是個好設計，但問題在於一致性。

API 回傳中同時存在 ann 和 announcement（公告）兩個不同的 key，這表示資料結構可能經歷過不嚴謹的遷移。此外，區塊順序、開關狀態與實際資料是分開儲存的，容易產生不同步的 bug。重構時應將每個區塊整合成一個包含 id, kind, enabled, position, payload 的完整物件。

1.4 結帳流程與安全性（PayPal 整合）

結帳流程是標準的兩步驟：

1. 客戶端請求 POST /api/paypal/create-order，伺服器在後端創建 PayPal 訂單。
2. 客戶端驗證後，請求 POST /api/paypal/capture 完成交易。

至關重要的原則：伺服器絕不能信任客戶端傳來的價格、折扣或總金額。伺服器必須根據資料庫中的商品價格、折扣規則與運費設定，自行計算所有金額，否則極易被竄改。

報告也點出，良好與不良的實作差異，在於是否有做到：

• 冪等性金鑰 (Idempotency Key)：防止因網路問題重複點擊而導致重複扣款。
• 交易鎖 (Transaction/Locking)：防止超賣。
• Webhook 簽章驗證：確認付款通知確實來自 PayPal。

1.5 後端推測與安全提醒

雖然無法 100% 確定後端語言（可能是 Node.js、PHP 或 Python），但報告提出了一個關鍵的安全疑慮：/api/track 這類追蹤端點如果無條件接收所有請求資料，可能成為被濫用注入垃圾資料的管道，導致資料庫快速膨脹。

此外，/api/orders/track 允許用短數字序號查詢訂單，這存在列舉攻擊（enumeration attack）風險，可能洩露他人購買資訊。建議使用簽署的追蹤令牌（signed tracking token）或需要配對訂單號碼與電子郵件/ZIP 碼。

2. 正面對決：客製化 SPA vs. WooCommerce

2.1 SEO（搜尋引擎最佳化）

這是最關鍵的差距。

• WooCommerce 預設優勢：伺服器直接傳送包含產品 HTML 的頁面，Google 爬蟲一來就能讀取所有內容。
• 純客戶端渲染 SPA（現狀）：Google 雖然有能力執行 JavaScript，但它會延遲索引，而且依賴 API 的可用性。如果渲染引擎超時或 API 出錯，爬蟲看到的就是空白頁。

Google 官方文件已明確指出，動態渲染（Dynamic Rendering）只是權宜之計，不建議長期使用 。最佳解是 SSR（伺服器端渲染）或 SSG（靜態網站生成）。

更糟的是，這個網站目前採用的是「偽 SPA」架構：伺服器為所有路由回傳相同的、幾乎空白的 HTML。這對 Google 來說是「軟 404」與「內容稀少」的雙重打擊 。甚至連社交媒體爬蟲（如 Facebook、LINE 的連結預覽）都因為不執行 JavaScript，永遠抓不到正確的標題與圖片。

2.2 速度與效能

• 客製化 SPA 的潛力：在後續導航中因為僅需交換資料，理論上非常快。靜態資源可透過 CDN 極速傳遞。
• WooCommerce 的基礎：若搭配快取外掛、物件快取（如 Redis）與圖片優化，小型 WooCommerce 網站的首頁載入速度（FCP）可能遠勝過成熟的 SPA。

關鍵區別：SPA 的痛點在於首次載入。它必須先下載並執行大量 JavaScript，再打 API 取得資料，最後才渲染出商品圖片與價格，這段「載入空白」的時間對使用者體驗傷害極大。

2.3 維護與擴展

• WooCommerce：將網站改成產品上架、訂單管理的維護成本轉移到生態系維護（更新 WordPress 核心、外掛、主題，處理相容性問題）。
• 客製化系統：將維護成本轉移到工程團隊（維護前後端程式碼、API、資料庫遷移、CI/CD 流程）。沒有外掛市場，所有功能都得自己寫或整合。

對於一個 16 個商品的網站，客製化架構帶來的複雜度很可能遠超過其帶來的彈性優勢。

3. 重構建議：打造更具前瞻性的新程式碼庫

報告最終提出了一個務實的建議：繼續走客製化路線，但徹底翻新架構，而非直接改用 WooCommerce。因為該網站的頁面建構器與品牌體驗已是其核心競爭力。

3.1 具體建議

前端層（Storefront）

• 框架：採用 Next.js（App Router） 或 Remix 這類混合渲染框架。這能讓你對不同頁面採用不同策略：
  • 產品頁、行銷頁：使用 SSG（靜態生成）或 ISR（增量靜態再生），讓 HTML 一載入就有內容，SEO 與社群分享瞬間獲得改善。
  • 購物車抽屜、個人化推薦：仍可使用客戶端元件（Client Components）處理互動。
• 資料驗證：在 API 邊界使用 Zod 等工具做類型驗證。
• 圖片優化：利用 CDN/物件儲存服務的圖片處理功能，指定寬度與格式。

後端層

• 語言與框架：可考慮 NestJS 或 Fastify（TypeScript），並搭配 PostgreSQL。
• 資料庫工具：使用 Prisma 或 Drizzle ORM 來確保型別安全的資料庫操作與遷移。
• 佇列系統：引入 BullMQ 等任務佇列處理非同步作業，如發送電子郵件、處理 Webhook 重試與訂單對帳。這樣 HTTP 請求就不會直接阻塞在郵件伺服器上。
• 監控與可觀測性：導入 OpenTelemetry 進行分散式追蹤，串聯整個結帳流程，方便除錯。

3.2 決策表格

結論

這個網站並非使用 WooCommerce、Shopify 等現成平台，而是一個技術含量不低的客製化專案。然而，其純客戶端渲染的架構、不盡理想的資料模型，以及潛在的安全漏洞，為其 SEO、效能與穩定性帶來了顯著風險。

對於技術團隊而言，最務實的路線不是盲目改回 WooCommerce，而是借鏡這個客製化架構的優點（如頁面建構器），並用現代化的渲染模式（如 SSR/SSG）與更嚴謹的資料設計，從根本上解決問題。這份報告提供了一份詳盡的藍圖，供開發團隊作為評估與執行的參考。