用 Next.js 與 Google Maps 打造租屋地圖平台

前言

找房子是每個人都會遇到的課題，但多數租屋平台的搜尋體驗並不直覺——你必須在一堆條列式的物件中來回切換，很難快速掌握物件的地理分佈。這就是我們開發「租窩 Zwoo」的初衷：用地圖的方式呈現租屋資訊，讓找房變得更直覺。

技術架構

整個專案可以分為三大部分：資料蒐集、後端處理、前端呈現。

資料蒐集

租屋資料來自公開的租屋平台，我們使用 Python 撰寫爬蟲程式，定期蒐集最新的物件資訊。蒐集的欄位包含：

• 物件標題與描述
• 租金、坪數、樓層
• 地址與經緯度座標
• 照片連結
• 發佈時間

爬蟲使用 requests 搭配 BeautifulSoup 進行 HTML 解析，對於需要 JavaScript 渲染的頁面則使用 Playwright 來處理。

資料清洗與結構化

原始資料往往不夠乾淨，常見的問題包括：

• 地址格式不一致：有些物件只有路名沒有門牌號碼，有些則包含樓層資訊
• 重複物件：同一個物件可能被多次刊登
• 缺少座標：部分物件沒有提供經緯度，需要透過 Geocoding API 轉換

我們建立了一套 ETL Pipeline，用 Python 進行資料清洗：

# 地址標準化範例
def normalize_address(raw_address: str) -> str:
    # 移除多餘空白與特殊字元
    address = raw_address.strip()
    # 統一「臺」和「台」
    address = address.replace("臺", "台")
    # 移除樓層資訊
    address = re.sub(r"\d+樓.*$", "", address)
    return address

前端地圖視覺化

前端使用 Next.js 搭配 @vis.gl/react-google-maps 來整合 Google Maps。每個物件會以 Marker 的形式顯示在地圖上，點擊後會彈出詳細資訊卡片。

為了效能考量，我們實作了幾個優化：

1. Clustering：當地圖縮放層級較小時，將密集的 Marker 合併為群組
2. Viewport Loading：只載入目前視窗範圍內的物件資料
3. Debounced Search：使用者拖動地圖時，延遲觸發資料請求，避免過多的 API 呼叫

遇到的挑戰

Google Maps API 費用控制

Google Maps API 是按使用量計費的，Geocoding 和 Maps JavaScript API 都有各自的計價方式。為了控制成本，我們採取了以下策略：

• 快取 Geocoding 結果：同一個地址只會查詢一次，結果存入資料庫
• Server-side 渲染地圖初始狀態：減少客戶端的 API 呼叫次數
• 設定每日用量上限：在 Google Cloud Console 中設定預算警報

大量 Marker 的效能問題

當地圖上有數千個 Marker 時，瀏覽器的渲染效能會明顯下降。我們最終採用了 Marker Clustering 搭配 Web Worker 來處理座標分群計算，確保地圖在任何縮放層級都保持流暢。

結語

「租窩 Zwoo」是一個從資料蒐集到前端視覺化的完整實踐。透過這個專案，我們深刻體會到：好的資料工程是產品體驗的基石。只有資料乾淨、結構化，前端的呈現才能真正為使用者帶來價值。

如果你也在做類似的地圖視覺化專案，歡迎參考我們的經驗，也歡迎透過社群與我們交流。