動態渲染與快取策略
Next.js ISR 的 revalidate 設定
快取策略像麵包店的補貨節奏——招牌吐司每小時補（熱門頁快、常重生），限定款一天一爐（長尾頁慢重生）；全部現烤會累死廚房。
03為什麼是現在學
動態站（Next.js 等）的 ISR/快取設定決定「內容更新多快反映」與「伺服器負擔」的平衡——設錯方向，要嘛內容過期要嘛主機爆炸。
04白話理解（對客戶簡報可直接引用）
以 Next.js 為例：ISR 的 revalidate 週期照內容時效訂——新聞列表分鐘級、產品頁小時級、關於頁天級。重點是「更新要能主動觸發重生」（on-demand revalidation）：編輯按下發佈，頁面立即重生，而不是等下一個週期。
05工具箱
- ▸框架的快取文件（Next.js revalidate） — 照頁型訂週期
- ▸HTTP Cache-Control／CDN 快取 — 另一層，規則要跟應用層一致
06怎麼做 · SOP 3 步（每步標產出物）
- 1頁型×時效需求表，訂各自 revalidate→ 快取策略表
- 2接發佈事件觸發 on-demand 重生→ 主動更新機制
- 3驗證：改內容→線上頁面在預期時間內更新→ 端對端驗證
07場景應用（實戰經驗）
- ◆改價格後線上頁面三天沒變——快取三層（應用/CDN/瀏覽器）各自為政。策略表就是為了讓三層講好同一套話。
08⚠️ 常見誤區
- ✕全部設 no-store 求安心——等於放棄快取，速度與費用同時惡化。
口訣
「照時效訂節奏，發佈能插隊。」
10里程碑 · 完成標準（可驗證）
- ☐快取策略表存在
- ☐發佈觸發重生驗證通過
學習者勾自己的進度；顧問勾客戶專案的交付——同一份標準，兩種用法。
12檢核方式與依據出處
人工判定：需要顧問訪談與專業審閱——這一段是顧問收費的理由。
- 🟢 官方明文Next.js：資料重新驗證（ISR）文件 ↗
- ⚠️ 業界慣例⚠️ 各頁型週期數字為實務慣例 ↗
依據等級決定計分權重（🟢×3／🔵×2／⚠️×1）——權重量的是「依據有多硬」， 不是「我們覺得多重要」。查無權威文件的判準，誠實標「業界慣例」。