Astro 四層能力：從靜態網站到互動應用
Astro 不只是把文章變成 HTML 的工具。除了靜態內容，它還能搭配原生 JavaScript、React／Vue／Svelte 等互動元件，必要時再接上伺服器功能。
理解這四種能力，就能從需求判斷需要多少技術，不必一開始便採用複雜的網站架構。
先建立觀念：這不是 Astro 的四種互斥模式。 同一個網站可以同時保留大量靜態頁面、少量 JavaScript、局部 Islands，以及需要後端的路由。
一張表理解四層能力
| 能力 | 用白話說 | 可以做什麼 | 是否一定要自架後端 |
|---|---|---|---|
| ① 靜態 HTML | 把內容做成能瀏覽的網頁 | 部落格、作品集、知識庫 | 不需要 |
| ② 原生 JavaScript | 讓網頁可以操作與計算 | 計算器、測驗、搜尋篩選 | 不需要 |
| ③ Islands 群島元件 | 讓複雜的互動區塊更好管理 | 互動儀表板、多步驟表單 | 不需要 |
| ④ 表單、會員與線上服務 | 讓網站能收資料、保存紀錄、登入或收款 | 報名表單、會員中心、線上付款、購物車與訂單 | 不一定；可用外部服務，較複雜的功能需要安全後端 |
① 靜態 HTML：建立內容與頁面
這是 Astro 最基本的能力。它在建置時，把 Markdown、資料與頁面模板轉成已經完成的 HTML，訪客打開網站就能閱讀。
能做什麼？ 部落格、知識庫、教學文章、服務頁、作品集、圖文資料庫與搜尋引擎友善的內容頁。例如用一份資料與同一套模板，生成整套塔羅牌百科，而不必逐頁手工製作。
何時使用？ 內容主要供閱讀、可預先產生，且不必每次訪問都重新運算時。若內容更新，通常重新建置即可。
② 原生 JavaScript：在瀏覽器加入互動
網頁即使是預先產生的 HTML，也能載入 JavaScript，讓使用者當下操作、計算或儲存資料。
能做什麼？ BMI、生命數字與房貸計算器；問卷評分、塔羅抽牌；文章搜尋、篩選、排序；動畫、結果卡片、瀏覽器本地儲存，以及呼叫允許瀏覽器存取的 API。
何時使用？ 小型互動工具或狀態管理不複雜的功能。這些互動可以放在純靜態託管的 Astro 網站中，通常不需要 React 或自己的伺服器。
注意：不要把私密 API Key 放在瀏覽器端。
③ Islands：把複雜互動交給局部元件
Islands（群島架構）是 Astro 的一種設計方式：頁面大多數內容仍是普通 HTML，只有真正需要互動的部分使用框架元件與客戶端 JavaScript。
例如，文章與導覽是靜態 HTML，但生日計算器使用 React、篩選面板使用 Vue、抽牌動畫使用 Svelte。這些元件可以在同一個 Astro 頁面中組合，不需要因此把整站改成單頁應用程式。
能做什麼？ 複雜表單、互動圖表、多元件協作、需要管理許多操作狀態的工具。
何時使用？ 當原生 JavaScript 開始需要大量手動更新畫面、追蹤元件狀態時，可以選用 React、Vue 或 Svelte。一般不必同時引入三套框架；選最適合的一套即可。
Islands 並不代表一定要有後端。常見的 Client Islands 可部署在靜態網站上。
④ 表單、會員與線上服務：讓網站能保存資料、登入與收款
前面三層讓網站可以被閱讀、操作、計算。到了這一層，網站還能把訪客提交的資訊送出去、保存資料，或與其他線上服務合作。
例如：有人填寫活動報名表，你收得到報名資訊；會員登入後，能看到自己的紀錄；顧客買了商品，網站能確認付款並建立訂單。
這些功能不代表一定要自己架伺服器。簡單需求可以使用現成服務；涉及私人資料、付款確認、訂單或權限管理時，才需要更加完整且安全的後端處理。
從簡單到複雜，可以做到什麼？
| 想做的功能 | 訪客實際會看到或做到什麼 | 通常怎麼完成 |
|---|---|---|
| ① 聯絡表單、活動報名 | 填姓名與 Email，送出留言或報名 | 嵌入 Google 表單，或使用現成表單服務 |
| ② 電子報與通知 | 留 Email 訂閱電子報、收到報名通知 | 串接電子報或寄信服務 |
| ③ 查詢資料 | 查詢活動名額、商品資訊或公開資料 | 讀取其他服務提供的資料 |
| ④ 保存紀錄 | 儲存問卷結果、預約資料，下次還能查看 | 使用提供儲存功能的線上服務或資料庫 |
| ⑤ 會員註冊、登入 | 建立帳號、登入、查看自己的內容 | 串接會員登入服務，處理身分與權限 |
| ⑥ 會員專屬功能 | 查看個人報告、學習進度、歷史訂單 | 安全讀取個人的雲端紀錄 |
| ⑦ 商品展示與購物車 | 選商品、加入購物車、計算總額 | 商品展示可以是靜態頁；購物車可在瀏覽器運作 |
| ⑧ 線上付款 | 用信用卡或其他支付方式結帳 | 串接第三方金流服務並安全確認付款 |
| ⑨ 訂單、庫存與優惠券 | 查訂單、使用優惠碼、確認是否有貨 | 需要可靠的資料儲存及訂單處理 |
| ⑩ 完整購物網站 | 從會員、挑商品、結帳到出貨追蹤 | 組合以上功能，加上商店管理後台 |
以實際網站來想像
情境 A：活動報名網站。 介紹活動與講師，訪客填寫 Google 表單即可報名。網站本身可以保持靜態，不必建立自己的會員系統。
情境 B：會員學習網站。 訪客先看到公開課程介紹，登入後才能閱讀付費內容、保存課程進度與個人紀錄。這時就需要登入驗證與安全的資料儲存。
情境 C：販售電子書或少量商品。 商品介紹可以是一般靜態頁面，點擊購買後前往第三方金流的結帳頁。若只販售少量數位商品，未必需要自建整套商店。
情境 D：完整網路商店。 訪客可以挑商品、加入購物車、使用折價券、付款與追蹤訂單。購物車的畫面本身可以在瀏覽器運作，但付款結果、訂單和庫存不能只依賴訪客裝置上的資料。
那 API、資料庫、SSR 是什麼？
這三個名詞可以先用一個簡單比喻理解：
- 資料庫像倉庫或檔案櫃：保存會員、報名、商品和訂單等紀錄。
- API 像服務窗口：讓網站向其他系統送出請求、取得資訊或要求執行工作，例如「幫我查這個會員的訂單」。
- SSR 像現場製作頁面：有人打開網站時，伺服器才依當下需要產生畫面，例如顯示該會員的個人資料頁。
資料庫不是 API 的一種。 網站可以透過 API 讀寫資料庫，也可能由伺服器程式直接存取資料庫；而 API 也可以用於寄信、查詢資訊或收款，完全不需要碰資料庫。
三者不是一定要綁在一起使用。例如，嵌入外部表單服務不需要你自建資料庫；有資料庫的網站也不一定要每頁都用 SSR。
進一步的技術名詞可以參考本文最後的「常見專有名詞」。
怎麼選擇？
從最少且足夠的能力開始：
- 只有文字與圖片？ 先用靜態 HTML。
- 需要計算、測驗或搜尋？ 加入原生 JavaScript。
- 互動介面越來越複雜？ 考慮一套框架與 Islands。
- 需要表單、會員、付款或保存資料？ 先看現成服務能否完成；需要自行管理私人資料或訂單時，再規劃安全的後端。
它們是可以搭配的工具，不是一定要一路升級的四個階段。
常見專有名詞
| 名詞 | 簡單解釋 |
|---|---|
| Astro | 以內容為中心的網站框架，可產生靜態頁面並按需加入互動或後端能力。 |
| HTML | 描述網頁內容與結構的標記語言。 |
| CSS | 控制網頁的排版、顏色與視覺樣式。 |
| JavaScript（JS） | 讓瀏覽器執行互動、運算與資料操作的程式語言。 |
| SSG（靜態網站生成） | 建置時先產生 HTML，訪客直接取得完成的頁面。 |
| CSR（客戶端渲染） | 由瀏覽器的 JavaScript 產生或更新畫面。 |
| SSR（伺服器端渲染） | 每次有請求時，由伺服器產生 HTML。 |
| Islands（群島架構） | 大多數頁面維持靜態，只讓需要互動的區塊載入相關 JavaScript。 |
| Hydration（水合） | 讓已渲染的介面載入客戶端程式，啟動互動功能。 |
| API（應用程式介面） | 不同系統交換資料或呼叫功能的方式。 |
| 資料庫（Database） | 儲存並管理會員、商品、訂單等可持續更新的資料。 |
| Webhook | 外部服務發生事件後，主動通知指定的伺服器端點，例如付款完成。 |
| Session（工作階段） | 用來維持登入狀態的機制，通常需要搭配安全的身分驗證。 |
| Endpoint（端點） | 接收請求並回應資料或操作結果的特定網址。 |
| Adapter（部署轉接器） | 協助 Astro 的伺服器程式配合 Cloudflare、Node.js 等環境運作。 |
| Client Island | 在瀏覽器執行互動邏輯的局部框架元件。 |
| Server Island | 由伺服器獨立渲染的局部動態內容，與 Client Island 不同。 |
React、Vue、Svelte 是什麼？
這三者都可以協助建立互動式使用者介面，也都能和 Astro 整合。
| 框架／函式庫 | 特色 | 常見用途 |
|---|---|---|
| React | 元件生態豐富，善於管理複雜的互動狀態 | 儀表板、複雜應用介面 |
| Vue | 模板語法直觀、響應式資料更新容易理解 | 表單、互動介面、篩選工具 |
| Svelte | 以編譯方式處理元件，語法相對精簡 | 小工具、動畫、互動元件 |
三者並沒有固定職務；相同功能通常都能實作。Astro 則負責組裝整個網站，決定哪些地方需要載入這些互動元件。