DealScout 運動折扣平台複盤

在各大運動品牌官網之間切換，只為了尋找一雙打折的跑鞋或一件心儀的外套，是許多運動愛好者的日常痛點。為了解決這個繁瑣的問題，筆者著手開發了「DealScout」——一個能自動爬取十多個運動品牌官網折扣商品，並為用戶營造「尋寶感」的折扣發現平台。

作為一個獨立開發的專案，筆者獨自負責了前後端分離架構、爬蟲工程與 SEO 導流的全端實作。在這篇文章中，我將完整複盤 DealScout 在爬蟲工程、SEO 導流，以及 MVP（最小可行性產品）取捨上的關鍵決策與實戰經驗。

專案成果與技術棧速覽

在進入細節之前，我們先來看看 DealScout 達成的階段性成果：

爬蟲覆蓋率：成功覆蓋十多個主流運動品牌（包含 Nike、Adidas、On、Hoka、Arc’teryx 等），累積爬取 5,000 件以上的商品。
技術架構：前端使用 Next.js 14 搭配 App Router，主打 SSR/ISR 以獲取搜尋引擎的自然流量；後端則由 Python FastAPI 負責提供 API 及執行爬蟲排程。
MVP 策略：為了優先驗證核心體驗，刻意砍掉帳號與金流功能，先以輕量化的方式上線。

在技術選型上，筆者針對不同需求選擇了最適合的工具：

層級	採用的技術
前端	Next.js 14 (App Router) + React + Tailwind CSS + Sentry
後端	Python FastAPI + SQLAlchemy + asyncpg
爬蟲	Scrapy + BeautifulSoup + Playwright（用於渲染 JS 頁面）
排程 / 遷移	APScheduler + Alembic
資料庫 / 部署	Supabase (PostgreSQL)、Vercel（前端）、後端容器平台

系統架構與資料流設計

DealScout 的整體架構設計非常清晰，主要圍繞在「如何高效獲取資料」與「如何讓搜尋引擎友善收錄」這兩個核心問題上。

瀏覽器（Next.js 頁面 + localStorage 暫存桶）
   -> Next.js (Vercel)：品牌頁靜態生成、API Routes 代理
   -> FastAPI：商品 API + 爬蟲排程器 + 折扣計算引擎
   -> Supabase PostgreSQL：products / brands / scrape_logs

我們的基本資料流運作邏輯如下：

定時爬蟲：由後端的排程器發動，定時抓取各大品牌官網的商品資料。
折扣計算：資料抓回後，透過折扣計算引擎算出折數與省下的具體金額。
寫入資料庫：將處理完的結構化資料寫入 Supabase PostgreSQL。
前端呈現：Next.js 前端讀取資料庫，並將其渲染呈現給使用者。

這套架構的核心目標在於對搜尋引擎保持極高友善度。我們希望當使用者在 Google 搜尋「某品牌 N 折」或相關折扣關鍵字時，DealScout 的頁面能被優先收錄，藉此帶入低成本的自然流量。

關鍵設計決策：MVP 階段的取捨

在獨立開發的過程中，資源與時間非常有限，因此「做什麼」和「不做什麼」同樣重要。以下是筆者在開發過程中的四大關鍵決策：

1. 為什麼前端選擇 Next.js SSR？

折扣導流平台的生命線在於「流量」。如果採用純前端渲染的 SPA（單頁應用程式），搜尋引擎很難爬取到動態生成的商品內容。因此，我們選擇 Next.js 14 的 SSR/ISR 技術。這並不是為了追求新技術，而是出於「用內容換流量」的商業考量，確保每一個折扣商品頁面都能被 Google 索引。

2. 為什麼爬蟲選擇 Python 生態系？

Python 在爬蟲領域的生態極其成熟。在面對一些重度依賴 JavaScript 渲染的品牌官網時，傳統的靜態 HTML 抓取工具（如 BeautifulSoup）會直接失效。此時，Python 生態中的 Playwright 就能粉墨登場，透過模擬真實瀏覽器行為，完美解決動態渲染頁面的抓取問題。

3. MVP 階段果斷砍掉認證與金流

為了快速驗證「尋寶」這個核心體驗到底吸不吸引人，筆者在第一階段刻意不做帳號註冊與金流系統。取而代之的是，我們利用瀏覽器的 localStorage 作為用戶的「暫存桶」（例如收藏喜愛商品）。這樣做不僅將驗證核心概念的開發成本壓到最低，也大幅降低了使用者的體驗門檻。

4. 從第一天就內建的爬蟲禮儀

合規與友善不是快上線時才要補上的補丁，而是在設計之初就必須考慮的規範。我們從第一天起就嚴格遵守目標網站的 robots.txt，並在代碼中加入隨機 2-5 秒的延遲與隨機的 User-Agent，避免對目標伺服器造成惡意負擔。

踩過的雷與應對方案

開發爬蟲產品的過程，本質上就是一場與目標網站的「攻防戰」。以下是筆者在過程中踩過的坑與實戰解法：

目標官網 HTML 結構頻繁修改、反爬機制升級
- 痛點：今天寫好的解析邏輯，下週官網一改版就報錯。
- 解法：建立逐站手動驗證機制與監控告警。必須建立一個認知——爬蟲是「需要持續維護的活物」，絕對不是寫一次就能一勞永逸的。
靜態抓取對 JS 渲染頁面失效
- 痛點：部分品牌官網打開後是一片空白，資料都靠後續 JS 載入。
- 解法：果斷引入 Playwright，進行真實瀏覽器渲染後再擷取 HTML。
選擇器誤殺商品名稱或 URL 解析錯誤
- 痛點：一條不夠精準的 CSS/XPath 規則，可能導致整批商品名稱錯亂或連結失效。
- 解法：擴充標籤集合、加上字串長度保護限制，並堅持逐站驗收，避免單一壞規則污染整個資料庫。
商品圖跨域限制（CORS）
- 痛點：直接引用品牌官網的圖片連結，常因對方的防盜鏈或跨域限制而無法顯示。
- 解法：統一透過後端代理（Proxy）或快取機制來載入圖片。

專案現況

目前 DealScout 已完成「爬蟲精化」的階段性任務。我們成功實現了十多個品牌的全覆蓋，累積了 5,000+ 件商品資料，並透過瀏覽器自動化完成了整體的流程驗收。

雖然專案目前尚未進入正式上線與商業化（例如導入聯盟行銷 Affiliate、或推出 Premium 付費訂閱）的階段，但整體的「核心體驗已得到驗證」，正處於蓄勢待發、等待規模化的狀態。

小結

回顧這段獨立開發的歷程，有兩點通用知識非常值得沉澱與分享：

爬蟲產品的隱形成本：任何依賴爬蟲資料的產品，其真正的開發成本從來都不是「寫出第一版爬蟲」，而是在於「如何持續且低成本地對抗目標網站的改版與反爬機制」。
流量思維先於技術選型：內容型產品在早期最需要想清楚的是「流量從哪裡來」。而 SSR + SEO 的架構組合，正是早期獲取低成本自然流量的黃金解法之一。

Jun 的學習筆記

探索