短網址服務實作：基於 Next.js 與 Upstash Redis 的短網址服務實作與架構分析
🤞 完整範例：Github Repo │ 👻 Live Demo：點我看 demo 本專案實作略過點擊次數統計及來源訪客分析。 短網址（Short URL）是什麼？ 短網址（Short URL）是將原始長網址透過 URL shortening 技術轉換為較短字串的結果，使連結更容易分享、記憶與管理。常見服務如 Bitly 與 TinyURL。 範例 原始網址（Original URL）： https://www.google.com/maps/place/Taipei+101+Shopping+center/@25.0341017,121.5642863,19z/data=!3m1!5s0x3442abb6d95eb43b:0xbfc3edc9e6aa3050!4m6!3m5!1s0x3442abb6da80a7ad:0xacc4d11dc963103c!8m2!3d25.0341222!4d121.5640212!16s%2Fg%2F11fx91ft3n?entry=ttu 短網址（Short URL）： https://url-shortener-doe.vercel.app/twLgDN 🥺🥺🥺 由於本專案部署於 Vercel，並使用其提供的免費子網域作為服務域名，而該網域本身字元較長，因此短網址的整體長度也相對受到影響（所以本篇範例和 Demo 的短網址會比較長喔）。 例如使用 reurl.cc 產生的短網址長度就只有這樣：https://reurl.cc/53ZNyR 為什麼需要短網址？ 縮短冗長 URL，節省字元空間 便於在字數受限的平台（如社群媒體、簡訊）分享 提升連結外觀整潔度與可讀性 可追蹤點擊次數、來源、地理位置等數據 可自訂短網址 slug，強化品牌辨識 隱藏原始網址中的參數與路徑結構 部分服務支援設定連結到期時間，控制存取期限 短網址的實際運作流程 當使用者點擊一個短網址時，系統背後其實會經歷一連串非常快速的查詢與轉址流程。從使用者的角度來看只是一次點擊，但在系統內部則包含「識別 → 查詢 → 重新導向」三個核心步驟。 整體流程可拆解如下： 1. 使用者請求短網址 使用者在瀏覽器輸入或點擊短網址：https://url-shortener-doe.vercel.app/twLgDN ，此時請求會被送往短網址服務的伺服器。這類伺服器通常是邊緣節點（Edge server）或 API server。 2. 系統解析短碼（Short Code） 伺服器會從 URL path 中解析出短碼：twLgDN，這個短碼是整個系統的核心 key。 3. 查詢對應的原始網址（Original URL） 系統會透過 key-value lookup 查詢儲存層，例如：Redis、Database、Cache layer。 ...