🚀 實戰大魔王：雲端平台容量限制與資安防禦

當你跟著前面的教學，終於把專案寫好準備推上雲端時，你很可能會突然遇到「專案太大，Git 卡死崩潰」或是「上傳失敗」的慘況。

這不是你的程式碼有 Bug，而是你觸碰到了各大雲端平台的**「硬體容量天花板」**！ 本章將為你盤點在部署與派發專案時，最常踩到的三大地雷，以及身為專業工程師該如何完美避開它們！

---

💣 地雷一：GitHub 的 100MB 檔案封殺令

發生情境

當你想要把自己的作品或原始碼打包成一個 ZIP 檔，放在專案裡面提供給客戶下載時。如果你直接在終端機輸入 zip -r my_project.zip .，你會發現這個檔案居然高達 好幾百 MB 甚至 1GB 以上！

當你開心地執行 git push 時，終端機會無情地報錯：

remote: error: GH001: Large files detected. You may want to try Git Large File Storage... remote: error: File my_project.zip is 737.00 MB; this exceeds GitHub's file size limit of 100.00 MB

為什麼會這樣？

因為你把開發過程中的「垃圾」跟「歷史紀錄」全包進去了：

1. node_modules：裡面有幾萬個套件檔案，隨便都破 500MB。
2. .git：這個隱藏資料夾記錄了你每一次的 commit，歷史越久檔案越大！
3. .next 或 dist：這都是編譯後的暫存檔案。

✅ 解決方案：寫一支專業的排除腳本

不要再手動打包了！在專案根目錄寫一支 package_source_code.sh 腳本，利用 zip 的 -x 參數精準過濾掉不必要的檔案，並順手把機密的 .env 金鑰拔掉替換成 .env.example。

# package_source_code.sh 範例
OUTPUT_DIR="public/source_codes"
name="my_project"

# 刪除舊的壓縮檔避免 zip 指令只做增量更新！(這點超重要)
rm -f "$OUTPUT_DIR/${name}_source.zip"

zip -r -q "$OUTPUT_DIR/${name}_source.zip" . \
    -x "node_modules/*" \
    -x ".git/*" \
    -x ".env" \
    -x ".env.local" \
    -x ".next/*" \
    -x "dist/*" \
    -x "public/source_codes/*" \
    -x ".vercel/*" \
    -x "*/.vercel/*" \
    -x "*.jpg" -x "*/*.jpg" \
    -x "*.png" -x "*/*.png"

echo "✅ 打包完成！"

執行結果：原本高達 700MB 的專案，打包後瞬間瘦身到 不到 1MB！從此推上 GitHub 暢通無阻！

---

💣 地雷二：Supabase 免費版的 50MB 檔案極限

發生情境

有些同學不想把 ZIP 放在 GitHub 或 Vercel (因為會佔用 Vercel 的部署空間配額)，所以決定把它傳到 Supabase Storage 裡面。 結果上傳到一半，直接噴出：

This project has a global file size limit of 50 MB.

為什麼會這樣？

Supabase 的 Free Tier (免費版) 雖然好用，但為了防止被當成免費網盤，嚴格限制了單一檔案上傳不得超過 50MB。如果你照著上面的腳本將專案瘦身到 1MB，那這將不再是個問題。

但如果你的檔案「真的就是超過 50MB」(例如裡面包含大量的教學影片或高解析度設計稿)，該怎麼辦？

✅ 解決方案：Google Drive 隱形轉跳法

一毛錢都不用花！

1. 把大檔案傳到你自己的 Google Drive，取得「知道連結的使用者皆可檢視」的網址。
2. 在前端畫面，還是做一個「下載」按鈕。
3. 關鍵：按鈕不是直接連到 Google Drive，而是連到你的後端 API (例如 /api/download)。
4. 後端 API 檢查這個人有登入且有付費後，執行 return NextResponse.redirect("你的Google Drive網址")。 這樣就能零成本繞過 50MB 限制，且能保有一定的權限防護！

---

💣 地雷三：放 public 資料夾的盜連危機

發生情境

你很聰明地把瘦身後的 ZIP 檔放在 Next.js 的 public/source_codes/ 資料夾底下。在前端也乖乖寫了判斷式：if (已付費) { 顯示下載按鈕 }。

為什麼這樣很危險？

public 資料夾在 Next.js 中，等同於「全網公開」的靜態資源！ 就算按鈕被藏起來，只要有心人士猜到或是拿到真實網址 (例如 https://your-domain.com/source_codes/my_project.zip)，他們直接貼在網址列就能免登入、免付費直接載走！

✅ 解決方案：Supabase Private Bucket ＋ 臨時簽名網址 (Signed URL)

這才是商業級知識付費平台該有的防護規格：

1. 建立私有儲存桶：在 Supabase Storage 建立一個名為 source-codes 的 Bucket，並設定為 Private (不允許公開存取)。
2. 後端核發臨時鑰匙： 當使用者點擊下載時，呼叫我們寫的後端 /api/download API。API 驗證權限通過後，使用最高權限的 Service Role Key 向 Supabase 申請一把「壽命只有 60 秒的臨時下載網址」。

// src/app/api/download/route.ts 核心防禦邏輯
import { createClient as createSupabaseClient } from '@supabase/supabase-js';

// ... 前方省略：驗證使用者是否有付費 ...

// 使用 Service Role Key 繞過 RLS 限制
const supabaseAdmin = createSupabaseClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

// 產生 60 秒後即失效的下載網址
const { data, error } = await supabaseAdmin
  .storage
  .from('source-codes')
  .createSignedUrl(fileName, 60, {
    download: fileName // 讓瀏覽器強制下載
  });

return NextResponse.redirect(data.signedUrl);

有了這道終極防護，別人拿到網址分享出去也沒用，因為 60 秒後網址就會自動失效變成廢紙！這就是軟體工程師變現的最強護城河！🏰