標準架構不適用的四種情況（含 SSR 解說）
靜態網頁＋無伺服器後端的標準架構有四種不適用情況：需要 SSR、需要即時推送、後端多前端共用、不在 Azure 生態系；含 SSR 白話解說與規格階段的兩個判斷提問。
定義：標準架構（靜態網頁＋Azure Functions＋SQL）不是萬用解。有四種情況要換積木：需要 SSR、需要長連線即時互動、後端要給多個前端共用、不在 Azure 生態系。
先弄清楚標準架構的本質
標準架構下，伺服器只給瀏覽器「空殼網頁＋一包程式」，瀏覽器自己執行程式、跟後端要資料、把畫面拼出來——所以打開系統會先看到轉圈圈，內容稍後才出現。這種「組裝發生在使用者瀏覽器裡」的做法叫 client-side rendering。好處是網站本體是純靜態檔案，部署簡單、幾乎免費。
不適用一：需要 SSR（伺服器端渲染）
SSR 跟標準架構正好相反——伺服器在送出網頁之前就先把資料查好、畫面組裝完，瀏覽器收到的是已填好內容的完整網頁，一打開就是成品。比喻：標準架構是 IKEA 模式（扁平包裝到家自己組），SSR 是成品家具直送（出廠前組好）。
SSR 只在兩種場景值錢：
- 搜尋引擎排名（SEO）——新聞、電商需要 Google 一來就讀到完整內容；要登入才能看的系統，Google 根本進不來，SEO 無從談起。
- 陌生訪客的第一印象——對外網站慢一秒就流失客人；同仁每天用的內部系統，開頭轉圈可以接受。
SSR 的代價：需要一台隨時在跑的伺服器負責每次請求的組裝，不能再用「純靜態檔案丟上去」的便宜做法，架構複雜度與費用都上一階。判斷式：對外的官網、商城、行銷頁 → 考慮 SSR；要登入的內部系統 → 不需要。
不適用二：需要長連線即時互動
標準架構的後端（Azure Functions）是「一問一答就掛斷」的模式，適合表單與查詢。如果要做「畫面自己即時跳動」——例如聊天室、多人同時編輯、看板即時刷新——需要伺服器主動推送（WebSocket 之類的長連線技術），Functions 不擅長，要改用一直在線的伺服器，或加專門的推送服務。
例外：機台訊號的即時看板可以用 Azure 的 SignalR 推送服務外掛解決，不必整個換架構。
不適用三：後端要給多個前端共用
如果同一套 API 要同時服務網頁、手機 App、還有別套系統，綁在單一網站專案裡的後端就不合適，該拆成獨立的 API 服務。
不適用四：不在 Azure 生態系
整套慣例（SWA、Functions、Entra ID）都是 Azure 的積木；若客戶或環境指定別家雲，同樣的概念要換成對應的積木（例如 Cloudflare、AWS 有各自的等價品），既有的骨架程式不能直接搬。
怎麼判斷：規格階段問 AI 兩個問題
這些情況都不是「標準架構不好」，是「題目不同」。判斷方法是在規格階段問 AI 兩個問題：
- 「這系統有沒有不登入的陌生訪客？」
- 「有沒有畫面要自己即時跳動的需求？」
兩個都沒有，就用標準架構，不要為了技術新潮而升級複雜度。
