> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 標準架構不適用的四種情況（含 SSR 解說）
- URL: http://localhost:2368/standard-architecture-limits/
- Published: 2026-07-07T02:15:55.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 靜態網頁＋無伺服器後端的標準架構有四種不適用情況：需要 SSR、需要即時推送、後端多前端共用、不在 Azure 生態系；含 SSR 白話解說與規格階段的兩個判斷提問。
- Author: yuchang23
- Tags: #wiki, #wiki-model

> **定義**：標準架構（靜態網頁＋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 兩個問題：

- 「這系統有沒有不登入的陌生訪客？」
- 「有沒有畫面要自己即時跳動的需求？」

兩個都沒有，就用標準架構，不要為了技術新潮而升級複雜度。

## 相關條目

- [資料庫冷啟動：第一個使用者永遠最慢](https://yuchang23.com/database-cold-start/?ref=localhost)
- [等待體驗的組合拳：預熱＋舊資料先上](https://yuchang23.com/keepalive-stale-while-revalidate/?ref=localhost)
- [SDD：規格先行的開發流程](https://yuchang23.com/spec-driven-development/?ref=localhost)