繼上一個 React 專案之後，這次我用 Nuxt 4 完成六角學院 2026 軟體工程師體驗營的部落格設計稿切版。和過去做 SPA 的經驗最大的不同，是這次必須正面理解 SSR（伺服器端渲染）——也因此開始真正理解 Nuxt 與 Vue 在執行流程上的差異，以及開發時需要注意的細節。

這篇文章主要整理本次使用 Nuxt 開發的學習歷程，內容涵蓋實作過程中的技術選型、遇到的問題與解法，以及對 SSR 開發模式的理解與反思，希望能為未來的自己留下完整紀錄，同時也提供給有類似需求的開發者作為參考。

另外也附上開發期間整理的基礎知識筆記 開發時記錄下來的基礎知識點筆記

• Live Demo：HexSchool2026 - Nelson Blog
• GitHub：GitHub Repo
• 使用技術：Nuxt 4 / Vue 3 / @nuxt/content / Pinia / Bootstrap 5 / Sass / Zod / Axios / Swiper
• 專案時程：2026.06.15 ~ 2026.06.24
• 網站部署：Vercel

一、 為什麼選擇使用 Nuxt​

我過去主要使用 React 搭配 Vite 開發專案，因此這次體驗營其實也可以選擇用熟悉的技術完成。不過考量到自己一直沒有正式接觸過 Nuxt，因此決定把這次專案當成學習機會，嘗試使用 Vue 生態系中的全端框架來完成整個部落格網站。

實際開發後才發現，Nuxt 並不只是幫 Vue 加上一些便利功能而已。它最大的特色在於內建 SSR（Server-Side Rendering） 能力，讓頁面能先在伺服器完成渲染後再傳送給瀏覽器。雖然這次選擇 Nuxt 的原因不是為了解決 SEO 問題，但在理解 SSR 的過程中，也開始認識到它在搜尋引擎優化、首屏載入速度以及使用者體驗上的優勢。

除此之外，Nuxt 還提供檔案式路由、自動匯入以及 Nitro 內建後端等功能，讓前後端開發能整合在同一個專案中。對於第一次接觸 Nuxt 的我來說，這些功能雖然提升了開發效率，但也讓我必須重新理解程式究竟是在伺服器執行，還是在瀏覽器執行。

而這其中最重要、也最容易讓人混淆的，就是 SSR 的運作模式。因此在正式開始切版與功能開發之前，我先花了一些時間理解 Nuxt 的執行流程，以及它與一般前端 SPA 應用之間的差異。

二、 理解 Nuxt SSR 的執行流程​

我一開始對於 SSR 有個錯誤的想像，以為是「有些元件在伺服器渲染、有些在瀏覽器渲染」。後來才發現完全不是這樣。

正確的模型是：整頁先在伺服器跑一次，產出 HTML，送到瀏覽器畫出來；然後同一批元件在瀏覽器再跑一次，接管那串 HTML，讓它變成可以互動的頁面。

伺服器：整頁元件執行一次 → 產出 HTML → 送到瀏覽器
                                    ↓
瀏覽器：先把 HTML 畫出來（使用者馬上看到，但還不能互動）
                                    ↓
瀏覽器：再把「同一批元件」跑一次，接管這些 HTML → 變成可互動

最後那個「接管」的動作有個專門名稱叫 Hydration（水合） ，是借用化學的比喻，把乾燥的靜態 HTML「加水」活化成有生命力、能互動的頁面。

理解這個模型後，很多事情就說得通了：Nav、Footer、文章頁......每個元件都是 「伺服器跑一次、瀏覽器再跑一次」，不是二選一。這也是 SSR 對 SEO 有利的原因——爬蟲一進來就拿到完整 HTML。

這裡整理我自己常回頭參考的對照表，記住「哪些程式碼會在伺服器跑」非常重要：

三、 開發前 Nuxt 幫你做好哪些事​

理解 SSR 的執行流程後，就正式開始切版與功能開發。這個階段最大的感受是：Nuxt 幫開發者省下了不少基礎設置的時間，讓我能更專注在畫面與功能實作上。

最有感的是檔案式路由。以前接觸 React 時，需要額外規劃與維護路由設定；在 Nuxt 中則是直接透過 pages/ 目錄建立頁面，例如 pages/index.vue 對應首頁，pages/blog/[id].vue 對應文章詳細頁。只要建立檔案，路由就會自動產生，開發體驗相當直覺。

版型管理則透過 Layouts 處理。我將網站共用的 Header、Footer 抽到 layouts/default.vue，各頁面只需要關注自己的內容。若特定頁面需要不同版型，也能透過 definePageMeta() 指定其他 Layout，避免在每個頁面重複撰寫相同結構。

另一個讓我印象深刻的是自動匯入機制。無論是 components/ 裡的元件、Vue 提供的 Composition API，或是自己撰寫的 composables/，都不需要手動 import。雖然方便，但也因此踩到一個小坑：Pinia 的 Store 必須放在 stores/ 目錄下才能被自動偵測，如果誤命名成 store/，Nuxt 就不會自動匯入。另外新增這類特殊目錄後，有時需要重新啟動開發伺服器，Nuxt 才會重新建立索引。

順帶一提，這次使用的是 Nuxt 4。和許多 Nuxt 3 教學不同，Nuxt 4 預設將前端程式碼集中在 app/ 目錄下，例如 app/pages、app/components、app/layouts 等。因此在查資料時，如果看到教學中的 pages/ 位於專案根目錄，需要先確認版本差異，避免照著操作卻找不到對應位置。

四、 透過 Markdown 管理文章資料​

骨架搭好後，下一步就是放入文章內容。

一開始我沒有打算把文章資料寫在 JavaScript 陣列裡，因為內容一多不但難維護，也失去了部落格「寫文章」的感覺。因此我選擇使用 @nuxt/content，把每篇文章都獨立寫成 Markdown 檔案，讓內容與程式碼分離。

在 Nuxt 中，只要建立 content/blog/1.md 這類檔案，就能像平常寫筆記一樣使用 Markdown 撰寫文章，支援標題、圖片、表格、程式碼區塊等常見格式。同時還能搭配 Frontmatter 存放文章資訊，例如日期、分類、封面圖片等。

為了讓這些欄位有型別檢查，我先在 content.config.ts 中定義 collection 與 schema：

import { defineContentConfig, defineCollection, z } from "@nuxt/content";

export default defineContentConfig({
  collections: {
    blog: defineCollection({
      type: "page",
      source: "blog/**/*.md",
      schema: z.object({
        description: z.string().optional(),
        image: z.string(),
        categories: z.array(z.string()),
        date: z.string(),
        dateFormatted: z.string(),
        views: z.number(),
        shares: z.number(),
      }),
    }),
  },
});

這段設定的作用是告訴 Nuxt：blog collection 底下的每篇文章都必須符合這個資料結構。如果 Frontmatter 少了必要欄位，或型別不符合定義，開發階段就能提早發現問題。

部落格index頁面資料，透過 queryCollection() 查詢：

const { data: blogs } = await useAsyncData("blog-list", () =>
  queryCollection("blog").all()
);

取得資料後，就能在頁面中渲染文章列表；而部落格詳細頁則可以透過 <ContentRenderer> 將 Markdown 內容轉換成 HTML 顯示。

對於個人部落格來說，這種模式很適合。文章本質上就是 Markdown 檔案，可以直接用 Git 版控，不需要另外架設資料庫或後台系統。如果未來要做成多人使用、可在線上發文的平台，再改用資料庫會比較合適。

這裡先埋下一個伏筆：雖然平常開發時一切正常，但後來部署到 Vercel 時卻遇到了一個意料之外的問題。追查後才發現，@nuxt/content 底層其實使用了 SQLite，而這也成了整個部署過程中最值得記錄的一個坑。

五、理解 Nuxt 的資料取得模式​

這一段是整個專案中我覺得最值得搞懂的地方。

剛接觸 Nuxt 時，我一直分不清 useAsyncData、useFetch、$fetch 和 axios 到底差在哪。後來才發現，答案其實都跟 SSR 有關。

在 Nuxt 中，頁面第一次載入時會先由伺服器執行一次，產生包含資料的 HTML 後再傳給瀏覽器。因此最大的差異不是「能不能抓到資料」，而是「抓到的資料能不能被瀏覽器重用」。

useAsyncData 與 useFetch 會在 SSR 階段取得資料，並把結果一起傳給瀏覽器。等到 Hydration 時，瀏覽器直接使用這份資料，不需要再次發送請求。

但如果在 <script setup> 中直接使用 $fetch 或 axios，Nuxt 不會幫忙傳遞資料，因此同一段程式碼可能在伺服器執行一次、瀏覽器再執行一次，造成重複請求。

理解這個差異後，四種工具的定位就變得很清楚：

我後來的理解其實很簡單：

進頁面就要顯示的資料，用 useAsyncData() 或 useFetch()；使用者操作後才需要發送的請求，用 $fetch() 或 axios。

實際套用到這次專案：

• 文章列表頁使用 useAsyncData()
• 文章詳細頁使用 useAsyncData()
• 其他透過 API 取得的頁面資料使用 useFetch()
• 聯絡表單送出使用 axios

例如文章資料是透過 queryCollection() 查詢 Markdown，因此使用 useAsyncData()：

const { data: blogs } = await useAsyncData("blog-list", () =>
  queryCollection("blog").all()
);

而如果是單純向 API 取得資料：

const { data } = await useFetch("/api/posts");

直接使用 useFetch() 會更簡潔。

另外，如果專案同時使用 axios 和 $fetch，還要注意兩者回傳格式並不相同。

// axios
const res = await axios.post(...);

console.log(res.data);

// $fetch
const res = await $fetch(...);

console.log(res);

錯誤處理的寫法也不同：

// axios
error.response.data.message;

// $fetch
error.data.message;

這個差異看起來不大，但我在撰寫聯絡表單錯誤訊息時就因此踩過一次坑，花了一點時間才發現是兩套 API 的設計不同。

六、建立前後端共用的表單驗證機制​

聯絡表單是這次專案中第一個完整串起前端、後端與 API 的功能，也是我第一次在 Nuxt 裡實際體驗全端開發的流程。

實作過程中，我學到一個很重要的觀念：

表單驗證應該同時存在於前端與後端。

前端驗證的目的，是讓使用者能立即看到錯誤訊息，提升操作體驗；後端驗證則是最後一道防線，因為任何人都可以直接呼叫 API，繞過前端檢查。

問題在於，如果前後端各自維護一套驗證規則，很容易出現不一致的情況：例如前端更新了規則，但後端沒有同步，或反過來導致行為不一致。

因此我選擇把驗證邏輯集中管理，並用 Zod 來定義 schema：

// shared/utils/schema.js
export const contactSchema = z.object({
  name: z.string().min(2, "請輸入姓名"),
  phone: z.string().regex(/^09\d{8}$/, "手機號碼格式不正確"),
  email: z.string().email("請輸入正確格式"),
  note: z.string().optional(),
});

Zod 採用宣告式寫法，可以一次描述所有驗證規則，比起手動寫一堆 if 判斷更清楚，也讓驗證邏輯集中在同一個地方，後續維護成本更低。

驗證時使用 safeParse()：

const result = contactSchema.safeParse(formData);

它不會像 parse() 一樣在失敗時直接拋錯，而是 回傳一個結果物件 ，包含 success 與 error，讓程式可以自行決定後續處理方式。對於表單這種「使用者本來就可能輸入錯誤」的場景特別適合。

前端送出邏輯如下：

const submitForm = async () => {
  
  const result = contactSchema.safeParse({
    name: name.value,
    phone: phone.value,
    email: email.value,
    note: note.value,
  });
  
  const result = contactSchema.safeParse(formData);

  if (!result.success) {
    toast.error(
      result.error.issues.map((i) => i.message).join("、")
    );
    return;
  }

  const res = await axios.post(
    "/api/send-contact",
    result.data
  );

  toast.success(res.data.message);
};

後端同樣使用這份 schema 再驗證一次：

export default defineEventHandler(async (event) => {
  const body = await readBody(event);

  const result = contactSchema.safeParse(body);

  if (!result.success) {
    throw createError({
      statusCode: 400,
      message: result.error.issues
        .map((i) => i.message)
        .join("、"),
    });
  }

  return {
    success: true,
    message: "已送出",
  };
});

這樣即使有人跳過前端直接呼叫 API，也仍然會被後端驗證擋下來。

另外在錯誤處理上也有幾個 Nuxt 的細節：

• createError() 要使用 message
• HTTP 狀態碼要使用數字，例如 400
• 前端接收錯誤時，可透過 error.data.message 取得後端回傳訊息

這些看似小細節，如果寫錯不一定會立刻報錯，但實際上會花不少時間在 debug。

回頭看這個功能，雖然只是簡單的聯絡表單，但卻完整串起了 Nuxt 的全端流程：共用驗證邏輯、前端表單、Server API 與錯誤處理都在同一個專案內完成，不需要額外拆成前後端兩個系統。

七、SSR 開發中的踩雷紀錄​

功能都完成後，在測試與部署階段遇到幾個 SSR 專屬的問題。回頭看，其實都可以用前面那張「程式碼在哪裡執行」的表來解釋。

1. Swiper 輪播的 hydration mismatch​

首頁打開時，Console 出現一整排紅字：Hydration node mismatch。 這個錯誤的意思是：伺服器先產生了一份 HTML，但瀏覽器接手後重新渲染時，兩邊的結果不一樣。 Swiper 剛好會在瀏覽器初始化時「自己改 DOM 結構」，例如加入 swiper-wrapper、swiper-pagination 這些元素。

結果就變成：兩邊不一致 → hydration mismatch。

• 伺服器輸出的 HTML（沒有 Swiper 結構）
• 瀏覽器初始化後的 DOM（被 Swiper 改過）

解法很直接：用 <ClientOnly> 包起來。

<ClientOnly>
  <IndexSwiperBlog />
</ClientOnly>

意思是：這個元件只在瀏覽器渲染，伺服器直接跳過。這樣就不會出現兩邊畫面不同的問題。

2. 伺服器沒有 window​

第二種錯誤是很經典的：window is not defined。 原因是 Nuxt 在 SSR 時會先在「伺服器」執行一次程式碼，而伺服器沒有瀏覽器 API，所以像這些都不存在：

• window
• document
• localStorage

例如：

localStorage.getItem("token")

在 SSR 階段會直接報錯。

解法有幾種：

• 放進 onMounted()（等瀏覽器載入後才執行）
• 用 <ClientOnly>
• 或判斷是否在 client 環境

另外像 Date.now()、Math.random() 這種「每次都會變的值」，也不建議放在 setup 最外層，否則伺服器和瀏覽器算出來不同，也可能導致畫面不一致。

3. 部署與 @nuxt/content 的 SQLite​

最後一個問題出現在部署。 這次使用 @nuxt/content 來管理 Markdown，它底層使用 SQLite 來儲存與查詢文章資料。 在本機開發時一切正常，但部署到 Vercel 時要理解一件事：

Vercel 這種 serverless 環境，和「永遠開著的伺服器」不一樣。

但實際情況是，這次專案沒有因此壞掉，原因在於 Nuxt Content 的運作方式：

• 在 build 階段，Nuxt 會先讀取 content/ 的 Markdown 檔案，整理成可查詢的資料結構
• 並且在需要的頁面進行 prerender（預先產生 HTML）

所以大多數頁面在上線後，其實是「直接使用 build 時已經準備好的內容」，而不是每次請求都即時去查 SQLite。

實務結論​

這一段踩坑後，我得到一個很簡單的理解方式：

• 只要會用到 window / document / 第三方會動 DOM 的套件（像 Swiper） → 幾乎都要注意 SSR，必要時用 <ClientOnly>
• 不確定會不會 SSR 出問題的程式 → 就先想「伺服器會不會也跑一次？」
• @nuxt/content 在部署時的重點不是「完全不查資料庫」 → 而是「Nuxt 會在 build 階段先把內容準備好，讓 runtime 盡量不用即時查」

SSR 最大的坑其實不是 bug 很難修，而是：你以為只有瀏覽器會跑的程式，其實伺服器也跑了一次

八、 Nuxt 中的 SEO 實作紀錄​

在 Nuxt 裡，我是直接把 SEO 設定放在 app.vue，用 useSeoMeta 先把整個網站的預設資訊補齊。Nuxt 會自動把這些設定轉成 HTML 的 meta tags，包含 Open Graph（LINE、Facebook 分享時的預覽卡片）以及 Twitter Card。

useSeoMeta({
  description:
    "Nelson 的設計與前端作品集，分享 UIUX 設計、網頁設計與前端開發的實務經驗。",
  ogType: "website",
  ogSiteName: "Nelson Blog",
  ogImage:
    "https://github.com/hexschool/2022-web-layout-training/blob/main/2026-web-camp/index_person.png?raw=true",
  twitterCard: "summary_large_image",
});

這一層設定的概念其實是「全站預設值」，像是網站名稱、描述、分享圖片。之後每一頁如果沒有特別設定，就會先套用這一份。 這樣做的好處是，不需要每一個頁面都重複寫 SEO，而是先在最上層建立一個基準。

也可以把它理解成：app.vue 做的是「網站的預設 SEO」，而不是「每一頁的 SEO」。

真正需要變動的是動態頁，例如文章頁，SEO 會跟著資料變化，所以要用函式寫法：

useSeoMeta({
  title: () => blog.value?.title,
  description: () => blog.value?.description,
  ogImage: () => blog.value?.image,
});

這樣 Nuxt 才會在資料載入後重新更新 meta，避免一開始就寫死。

整體來看，Nuxt 的 SEO 模型其實很直覺： 先在 app.vue 設一個「全站預設」，再在需要的頁面「覆蓋成動態內容」。

做完這一步之後會有一個很明顯的感受：Nuxt 不只是幫你做 SSR，也把 SEO 這一層的基礎流程一起整理好了。

九、 專案心得​

1. 觀念先行，比急著寫 code 更省時間​

這次最大的體會是：文章裡遇到的幾個坑——Swiper、window、雙重抓取——追根究柢其實都來自同一件事：沒有先搞清楚「哪些程式碼會在伺服器執行」。

一旦把 SSR 的心智模型和那張執行對照表建立起來，很多問題其實不用查文件，自己就能推得出來。

框架的規則看起來很多，但背後通常只有一條主線。先抓住主線，細節才不會變成死記。

2. 遇到 hydration mismatch 不需要慌​

這個錯誤大多來自兩種情況：使用了時間、亂數、視窗寬度等「會變動的值」，或是第三方套件在瀏覽器動態改 DOM。 對應方式其實很固定：

• 會動 DOM 的元件 → 用 <ClientOnly>
• 只該在瀏覽器跑的邏輯 → 放進 onMounted

理解原因之後，這個原本看起來很嚇人的紅字，其實只是 SSR 中最容易處理的一類問題。

3. 驗證一定要前後端一起做​

前端負責體驗，後端負責安全，這兩者不能只選一邊。 這次用 shared/ 搭配 Zod 共用 schema，是我覺得最乾淨的做法，也避免了「前後端規則不同步」的問題。

安全性永遠不能只依賴前端，因為前端一定可以被繞過。

十、總結​

從 React 的 SPA 開發，到這次第一次完整做 SSR 專案，最大的收穫其實只有一件事：

開始真正理解「程式碼在哪裡執行」。

Nuxt 一開始會讓人覺得規則很多，但當 SSR 這條主線建立起來之後，剩下的其實就是查文件和補細節。

這次從零到部署的完整過程，也讓我更清楚一件事：

• 不是框架變難了，而是以前沒有看見它真正運作的方式。
• 希望這份紀錄可以幫正在學 Nuxt 的人，少踩一些我踩過的坑。

第一次部署網站時，我查了很多教學，幾乎都推薦用 GitHub Pages。但真正開始部署自己的專案後，才發現一個問題：不同專案適合的平台其實不一樣，卻很少有人解釋背後的原因。

後來深入了解才知道，這四個平台本來就是為了不同的使用情境而設計。它們底層的架構不同，也直接影響能提供的功能、適合的專案類型，以及後續可能遇到的成本與限制。

這篇文章會從平台架構開始介紹，整理四個平台的差異、各自的優缺點，以及實際部署時常遇到的限制與成本考量。另外，也會補充一些部署過程中常見但不容易理解的專有名詞，希望能幫助你在選擇平台時，更清楚知道哪一個才適合自己的專案。

本文涵蓋：​

• 各平台底層架構與技術選型
• 隱藏限制與成本引爆點
• 專有名詞白話解析（CDN、Serverless、Cold Start、Edge Function 等）
• 選平台情境對照表

一、GitHub Pages：最單純，但也最受限​

底層在做什麼​

GitHub Pages 背後是依賴 Fastly 這類 CDN 服務來分發靜態檔案。過去它高度綁定 Jekyll 這個靜態網站產生器，但現在已經全面轉向整合 GitHub Actions。

這代表：只要你能寫出正確的 Action 腳本，任何框架（React、Vue）都能打包後部署上去。但這也是它最大的限制，你能部署上去的，只有打包後的靜態檔案，完全沒有資料庫或後端運算能力。

CI/CD 體驗​

CI/CD 部分完全依賴 GitHub Actions，優點是高度客製化；缺點是沒有像 Vercel 那種「開箱即用」的 PR 預覽環境。你需要自己寫腳本，甚至搭配其他工具才能實現。

隱藏限制​

• 流量限制：每月有 100GB 的頻寬軟限制（Soft Limit），超過雖然不一定立刻停用，但會收到警告。
• 開源限制：免費帳號的 Repo 必須是 Public，才能免費使用 GitHub Pages。若要部署私有庫，需要升級 GitHub Pro 或 Team 方案。

適合用在​

個人履歷、開源專案說明文件、靜態部落格。

參考：GitHub Pages 官方文件 ／ 使用量與限制

二、Vercel：開發體驗業界標竿，但商用成本要算清楚​

底層在做什麼​

Vercel 本質上是建立在 AWS 和 Cloudflare 之上的「高級封裝」。它把你的前端專案拆解成三個部分：

• 靜態資源 → 丟上全球 CDN
• API 路由 → 轉換成 AWS Lambda（Serverless）
• Middleware → 轉換成 Edge Functions（邊緣運算）

理解這件事很重要。Vercel 並不是「幫你租一台伺服器」，而是把你的程式碼轉譯成不同形式，分散部署在各種雲端基礎設施上。

CI/CD 體驗​

這是 Vercel 最強的地方。只要發布一個 PR，Vercel 幾秒內就會生成一個獨立的預覽網址，甚至支援團隊直接在預覽頁面上留言（Comment on Preview）。對於需要讓 PM 或設計師 review 畫面的團隊來說，這個功能幾乎沒有替代品。

隱藏成本​

• 冷啟動（Cold Start）：因為 Serverless 的特性，API 一段時間沒被呼叫就會進入「休眠」。下次有人呼叫時，需要幾百毫秒到幾秒的「重新開機」時間。對於要求超低延遲的場景，這是個大問題。
• 團隊席位費極貴：免費版（Hobby）只限個人非商業用途。一旦升級 Pro（商用），每個團隊成員每月 $20 USD。人數多起來，費用會很快超出預期。
• 附加服務費：圖片最佳化（Image Optimization）、頻寬超標費用在流量暴增時非常可觀。

適合用在​

Next.js / React 專案、需要極速全球 CDN 與絕佳 SEO 的電商前端。

參考：Vercel 官方文件 ／ 方案與定價 ／ Serverless Functions ／ Edge Functions

三、Render：最接近「自己租主機」的現代替代方案​

底層在做什麼​

Render 主要託管在 AWS 和 GCP 上，但和 Vercel 的「無伺服器」方向完全不同，走的是容器化（Container-native） 架構。

你只要提供一個 Dockerfile，Render 就幫你建立成一個常駐執行的容器。這個差異很關鍵——常駐容器代表可以：

• 跑長連線（WebSocket、遊戲伺服器）
• 執行背景任務（Background Workers）
• 保持連線到資料庫，不需要每次請求都重新建立

同時 Render 也支援微服務架構，你可以建立內部 API 伺服器與資料庫，它們透過 Render 的私有網路溝通，完全不暴露在公開網際網路上。

隱藏限制​

• 免費版會「睡覺」：免費的 Web Service 只要閒置 15 分鐘就會休眠，下次有人訪問時，喚醒時間可能長達 30 秒到 1 分鐘。對使用者體驗影響極大。有些開發者會寫腳本每 10 分鐘 Ping 它一次防止休眠，但這有違規風險。
• 編譯時間限制：免費方案每月只有 500 分鐘的 Build 時間，對大型專案來說容易耗盡。

適合用在​

全端應用程式、需要連接資料庫的 API 伺服器、爬蟲程式、Discord 機器人。

參考：Render 官方文件 ／ 免費方案限制 ／ PostgreSQL 資料庫

四、Cloudflare Pages：頻寬無上限，但底層完全不一樣​

底層在做什麼​

Cloudflare Pages 不是部署在某個雲端廠商的機器上，而是直接部署在 Cloudflare 遍布全球 300 多個城市的邊緣節點上。

更關鍵的是，它的 Pages Functions 底層不是傳統的 Node.js 容器，也不是 AWS Lambda，而是基於 V8 Isolates 引擎。

這個技術選型帶來一個其他平台都比不上的優勢：幾乎 0ms 的冷啟動時間。V8 Isolates 是 Chrome 瀏覽器用來跑 JavaScript 的超快引擎，啟動速度極快，完全沒有傳統 Serverless 的冷啟動問題。

隱藏限制​

這個架構最大的痛點是 Node.js 相容性問題。因為底層是 V8 Isolates 而不是標準的 Node.js 環境，某些依賴 Node.js 原生模組（如 fs、path、特定加密庫）的後端套件無法直接運行，需要尋找替代方案或使用 Polyfill。

另外，免費版的函數 CPU 運算時間限制在 10ms 以內（付費版為 50ms）。這代表你不能在邊緣節點做太複雜的資料處理，只適合輕量的 API 轉發或資料庫讀寫。

適合用在​

高流量靜態網站、極度重視載入速度與安全性的全球化專案。

參考：Cloudflare Pages 官方文件 ／ Pages Functions ／ V8 Isolates 原理

五、進階規格比較表​

六、專有名詞白話解析​

這些詞在各平台的文件和介紹裡會一直出現，但大多數教學都假設你已經懂了。整理在這裡備查。

部署與自動化​

CI/CD（持續整合與持續部署）

以前工程師要把網站上線，需要手動打包、連線伺服器、覆蓋舊檔案。CI/CD 是把這個流程自動化的概念——你只要把程式碼 Push 到 GitHub，系統就自動測試、打包並更新到正式網站。

📖 GitHub Actions 文件

PR（Pull Request）

團隊合作時，工程師寫完一段新功能，提出「合併請求」，讓其他人審查程式碼。Vercel 的「PR 預覽」讓這個功能更強大——新功能在正式上線前，先產生一個臨時網址，讓 PM 或 QA 直接點進去測試。

雲端架構​

PaaS（Platform as a Service / 平台即服務）

就像租一間「水電裝潢都弄好」的店面。你只需要把商品（程式碼）擺進去就能開始營業，不用自己蓋房子（管底層作業系統、安全性修補）。Render 就是一種 PaaS。

什麼是 PaaS（AWS 說明）

Docker / Container（容器化）

把程式碼、需要的套件、設定檔全部打包成一個「標準規格的貨櫃」。不管把它搬到哪台電腦或哪個雲端平台，執行結果都一模一樣。再也不會發生「在我電腦上明明就可以跑啊」的問題。

Docker 入門指南

Serverless（無伺服器）

其實還是有伺服器，只是你不需要管它。傳統租主機是包月制，不管有沒有流量都要付錢；Serverless 則是「有人觸發你的 API，系統才瞬間啟動一小塊運算資源」，用完立刻回收。省錢，但代價是冷啟動問題。

Serverless 概念（Cloudflare Learning）

Cold Start（冷啟動）

Serverless 為了省資源，沒人用時會進入「休眠」。當突然有訪客進來，系統需要「重新開機」，這段讓使用者覺得卡頓的等待時間就是冷啟動。從幾百毫秒到幾十秒不等，取決於平台。

速度與效能​

CDN（Content Delivery Network / 內容傳遞網路）

全球的「物流發貨中心」。如果你的主機在美國，台灣的使用者連線過去會很慢。CDN 在全球各地建立節點，把靜態資源複製到離使用者最近的位置。台灣使用者就從台灣節點抓資料，載入速度瞬間提升。

什麼是 CDN（Cloudflare）

Edge Computing（邊緣運算 / Edge Functions）

CDN 的進階版。原本 CDN 只能放「靜態圖片」，邊緣運算讓後端程式碼也能直接在離使用者最近的全球節點上執行。使用者根本不用連回遠在美國的主機，在台灣的節點就直接算好資料回傳。

Vercel Edge Functions ／ Cloudflare Workers

V8 Isolates

Google Chrome 用來執行 JavaScript 的超快引擎。Cloudflare 把它拿來跑後端程式，因為它啟動時間幾乎是 0 毫秒，直接解決了 Serverless 的冷啟動問題。

How Workers Works（Cloudflare）

其他重要概念​

WebSocket / 長期連線

傳統網頁是「一問一答」：使用者點一下，伺服器給一次資料。WebSocket 則是雙方建立一條「不中斷的雙向水管」，伺服器可以隨時主動把新資料推給使用者。常用於即時聊天室、股票看盤、多人連線遊戲。

📖 WebSocket API（MDN 中文）

WAF（網頁應用程式防火牆）& DDoS（分散式阻斷服務攻擊）

DDoS 是駭客操控大量中毒電腦同時湧入你的網站，把伺服器塞爆癱瘓。WAF 是站在網站前面的「高階保全」，負責過濾掉惡意的攻擊指令。

📖 什麼是 DDoS（Cloudflare） ／ 什麼是 WAF（Cloudflare）

Vendor Lock-in（平台綁定 / 供應商鎖定）

如果你用了太多某個平台的獨家功能，導致程式碼完全迎合它，未來想搬家時幾乎要全部重寫，這就是平台綁定風險。Vercel 和 Cloudflare 的專屬功能都有這個問題，選用時要先想清楚。

📖 Vendor Lock-in（Wikipedia）

七、心得​

比較到最後，我發現選平台其實沒有絕對的好壞，而是看你的專案需求。只要先想清楚下面三件事，通常就能很快做出選擇。

1. 專案需要後端嗎？​

如果只是靜態網站，像是作品集、部落格或形象網站，GitHub Pages 或 Cloudflare Pages 就已經足夠；但如果需要 API、資料庫或長時間運行的服務，就需要能部署後端的平台，例如 Render。

2. 你比較在意開發體驗，還是長期成本？​

如果重視部署流程、CI/CD、PR Preview 等開發體驗，Vercel 依然是非常成熟的選擇，尤其適合團隊協作。不過在商業團隊中，也要將每位成員的席位費納入長期成本考量。

3. 專案流量與部署環境有哪些需求？​

如果預期流量較高，或希望有完善的 CDN 與 DDoS 防護，Cloudflare Pages 的免費頻寬與全球網路會是很大的優勢。但如果後端需要依賴 Node.js 原生執行環境，則要先確認是否與 Cloudflare Workers 的執行模型相容。

最後與AI討論後整理成一張情境對照表：​

資料來源​

• GitHub Pages 官方文件
• Vercel 官方文件
• Render 官方文件
• Cloudflare Pages 官方文件
• Docker 入門指南
• MDN — WebSocket API
• Cloudflare Learning Center

一個以「把 Yes 變成 Step」為核心精神的整合性步道檢索平台，將分散的步道資訊收斂到單一介面，讓使用者依地區、難度、行走時間與景觀類型快速篩選，把「想出去走走」的念頭，轉化為實際可行的行程規劃。

• Live Demo：YeStep
• GitHub：GitHub Repo
• 使用技術：Vite / React / React Router / Redux Toolkit / Bootstrap 5 / Sass / Axios / JSON Server / JavaScript / Swiper / Lottie / Chart.js / Git / GitHub
• 團隊角色：組長 / 前端開發(React) / API 模擬與部署(JSON Server)
• 專案管理：Notion / GitHub / Discord
• 專案時程：2025.10.15 ~ 2026.02.28
• 網站部署：Render

一、 主題發想​

組隊初期討論主題時，組員中有一位是親子家庭使用者，分享她在尋找適合帶孩子走的步道時，常面臨資訊分散的問題：步道資料散落在政府網站、登山部落格與社群論壇之間，難以一次比較難度、路程與適合對象。我們以此為起點延伸思考目標客群，發現這個痛點不只存在於親子家庭——對忙碌的上班族、尋求身心療癒的使用者而言，「想走出去」與「實際成行」之間，往往卡在資訊整合度不足這道門檻。

YeStep 因此定位為一個整合性步道檢索平台，將分散的資訊收斂到單一介面，讓使用者依地區、難度、行走時間與景觀類型快速篩選，把「想出去走走」的念頭，轉化為實際可行的行程規劃。

二、 專案協作方式​

整個專案歷時約 5 個月，採每週一次 75~90 分鐘的固定會議追蹤進度，並使用 Notion 管理專案進度與文件，透過 Git / GitHub 進行版本控制與協作開發。

三、 使用者故事​

延續上個專案驗證有效的 MVP 思維，我們在開發前先盤點所有頁面，把「首頁、檢索頁、檢索詳細頁、主題活動頁」設定為核心必做項目，會員中心則列為選做。考量到上個專案最終成果偏向靜態切版展示，這次我們設定的核心目標是「讓網站真的動起來」——不只要切版完成，還要串接 API、有實際的篩選、搜尋與跳轉邏輯。會員中心在團隊餘力下也順利完成。

在功能權限上，我們依使用者狀態設計兩個層級：一般使用者可瀏覽所有步道資訊、使用篩選與搜尋，會員則額外擁有收藏步道、修改個人資料等功能。考量到「想收藏才願意註冊」是更自然的轉換動機，我們設計了一條漸進式的引導流程，未登入使用者點擊收藏時，會先彈出提示導向登入頁。若還沒有帳號，再進一步引導至註冊頁。讓註冊這件事從「先註冊才能用」，變成「因為想用所以註冊」。

針對三類目標使用者：忙碌上班族、親子家庭、尋求療癒的人。檢索頁採取多維度篩選設計，包含地區、難度、行走時間與景觀類型。不同族群可以用不同組合，找到真正適合自己的路線。

四、 網站地圖與 Wireframe​

網站地圖、流程圖與 Wireframe 由團隊在 Miro 上共同繪製。過程中由組內具 UI/UX 經驗的組員協助，把跨頁會重複使用的元件（如卡片）統一定義出來，讓後續切版時大家有共同的設計依據，也減少重工的成本。

• 🔗 Miro Wireframe

設計過程中最有印象的取捨，是首頁主視覺 Banner 的呈現方式。最後決定做成「影片」與「步道圖片輪播(Swiper)」之間的切換式設計，讓使用者可以依當下的瀏覽心情，選擇喜歡的方式探索網站。

五、 UI 設計稿​

線稿完成後，團隊將整體想法與品牌方向整理出來，邀請專業 UI/UX 設計師協作，在 Figma 上產出完整的視覺設計稿，包含色票、字體規範、元件樣式與各頁面的高保真畫面。設計師加入後，介面從「能用」進階到「符合品牌氛圍」，也讓後續切版有了清楚一致的依據。

六、 專案架構​

yestep/
├── public/                  # 靜態資源
│   └── logo.png
├── src/
│   ├── assets/
│   │   ├── images/          # 圖片資源（依頁面分類）
│   │   ├── scss/            # 樣式檔案
│   │   │   ├── _variables.scss
│   │   │   ├── _variables-dark.scss
│   │   │   ├── base/        # 基礎樣式
│   │   │   ├── components/  # 元件樣式
│   │   │   ├── layout/      # 佈局樣式
│   │   │   ├── page/        # 頁面樣式
│   │   │   ├── util/        # 工具樣式
│   │   │   └── all.scss     # 樣式進入點
│   │   └── videos/          # 影片資源
│   ├── components/          # 共用元件（24 個）
│   │   ├── Nav.jsx          # 導覽列
│   │   ├── Footer.jsx       # 頁尾
│   │   ├── HeroSwiper.jsx   # Hero 輪播
│   │   ├── PopularTrails.jsx # 熱門步道
│   │   ├── SearchBar.jsx    # 搜尋列
│   │   ├── TrailCard.jsx    # 步道卡片
│   │   └── ...
│   ├── data/                # 靜態資料
│   ├── pages/               # 頁面元件
│   │   ├── Home.jsx         # 首頁
│   │   ├── TrailSearchPage.jsx # 步道搜尋
│   │   ├── TrailDetail.jsx  # 步道詳情
│   │   ├── TrailTag.jsx     # 步道分類
│   │   ├── Theme.jsx        # 主題活動
│   │   ├── Member.jsx       # 會員中心
│   │   ├── Login.jsx        # 登入
│   │   ├── Register.jsx     # 註冊
│   │   ├── ProtectedRoute.jsx # 路由守衛
│   │   └── NotFound404.jsx  # 404 頁面
│   ├── server/              # API 設定
│   │   └── api.js
│   ├── slices/              # Redux Slices
│   │   ├── authSlice.js     # 認證狀態
│   │   └── infoSlice.js     # 資訊狀態
│   ├── utils/               # 工具函式
│   │   ├── error.js         # 錯誤處理
│   │   └── formatNumber.js  # 數字格式化
│   ├── App.jsx              # 根元件
│   ├── main.jsx             # 應用進入點
│   ├── router.jsx           # 路由設定
│   └── store.js             # Redux Store
├── db.json                  # JSON Server 資料庫
├── server.cjs               # API 伺服器設定
├── index.html               # HTML 進入點
├── vite.config.js           # Vite 設定
├── package.json
└── .env                     # 環境變數

七、 個人負責開發項目​

1. 路由系統​

使用 React Router 在 router.jsx 中集中管理所有路由配置，並依照頁面是否需要登入權限進行分層。

ProtectedRoute — 路由守衛

路由守衛這個概念課程中有帶，但當時還不太熟悉實際的應用情境，因此我主動詢問 AI、釐清它的運作原理後再實作出來。

具體做法是建立一個 ProtectedRoute 包裝元件：在元件內讀取 Redux 的登入狀態，未登入就用 <Navigate> 自動導向登入頁，登入後才渲染原本的子元件。

const ProtectedRoute = ({ children }) => {
  const { token } = useSelector((state) => state.auth);
  const location = useLocation();

  if (!token) {
    return <Navigate to="/login" state={{ from: location }} replace />;
  }
  return children;
};

在 router 設定中只需要把需要保護的頁面用 <ProtectedRoute> 包起來，就能達到統一的權限控管，不需要在每個頁面內各自寫驗證邏輯。

2. 假資料 API 建置與部署​

考量到課程主軸是前端、團隊裡也沒有後端組員，為了讓專案能真正串接 API 而不是寫死資料，我主動承擔了模擬後端的建置與部署工作。

假資料來源與整理

組員從政府 Open Data 平台找到合適的步道 API，我們以此為基礎做資料轉換，保留需要的欄位、移除不必要的內容，並依照前端使用情境補上自訂的 key value（例如收藏狀態、自訂標籤等）。

Node.js 伺服器建置

• 使用 json-server 作為資料庫與伺服器核心。
• 使用 json-server-auth 作為權限驗證中間件，讓 API 支援 POST /register、POST /login 並自動生成 JWT token。
• 設計自訂的 middleware 解決 CORS 跨網域存取問題，並將 API 伺服器部署到 Render 平台上。

3. 狀態管理與全域訊息系統​

authSlice — 會員登入狀態管理

使用 Redux Toolkit 的 authSlice 統一管理會員狀態。串接登入 API 成功後，將伺服器回傳的 accessToken 與 user 資料透過 dispatch 更新至全域 State，並同時將 Token 存入 Cookie 中（7 天效期），讓使用者在關閉瀏覽器後重開，仍能保持登入狀態。

infoSlice + Toast 元件 — 全域訊息系統

設計一套全域 Toast 通知機制，讓任何元件都可以透過 dispatch(createMessage({ text, type })) 觸發畫面右上角的提示訊息。訊息類型分為「成功」與「錯誤」兩種，分別對應收藏成功、API 連線失敗等情境。

這套架構讓「狀態變化 → 視覺呈現」完全解耦，後續任何新功能需要彈出提示時，只要一行 dispatch 就能完成。

4. 專案基礎建置與全域樣式​

延續上個專案使用 Bootstrap 5 + Sass 的經驗，這次依照設計師提供的 Figma 設計稿，將整套設計系統落地為 SCSS 變數，建立全網站共用的設計依據。主要包含：

• 色票系統：依設計稿規範定義品牌主色與中性色階變數。
• 字級系統：自訂排版 class，統一全網站的文字層級與字重。
• 元件樣式：自訂圓角、間距與按鈕樣式，搭配 Bootstrap 既有 utility class 使用。

5. 頁面切版與功能​

5-1. 登入 / 註冊頁

完整實作登入與註冊流程，搭配 react-hook-form 處理表單驗證。

登入流程：

1. 透過 js-cookie 將 token 存入 Cookie（7 天效期）
2. dispatch 至 Redux 更新登入狀態
3. 透過 infoSlice 顯示「歡迎回來，OOO」的成功訊息
4. 透過 location.state 記住登入前的來源頁面，讓使用者登入後自動回到原本想去的位置
5. 錯誤訊息依錯誤類型分類顯示（如帳號密碼錯誤 vs 伺服器連線失敗）

5-2. 步道檢索詳細頁 (TrailDetail)

詳細頁是整個專案中功能最密集的頁面，整合了 API 串接、收藏狀態管理、相關推薦、動態跳轉與 RWD 等多個面向。

1. 資料載入策略：Promise.all 並行請求

詳細頁進入時需要載入三筆資料：當前步道的詳細資訊、同系統的相關推薦、其他系統的相關推薦。改用 Promise.all 讓三支 API 同時發出請求，總等待時間以最慢的一支為準，能顯著縮短頁面首屏載入時間。

const [detailRes, centralRes, allRes] = await Promise.all([
  TrailsApi.get(`/trails/${id}`),
  TrailsApi.get("/trails?trail_system_like=中央山脈"),
  TrailsApi.get("/trails"),
]);

2. 相關推薦：分類隨機抽取

推薦邏輯設計成兩種類型分開呈現：

• 中央山脈脊梁國家步道系統：與當前步道屬於同一山脈系統，提供「延伸體驗」。
• 其他步道系統：跳脫當前山脈系統，提供「探索選項」。

兩類資料各自從 API 結果中隨機抽取 3 筆，避免每次進詳細頁都看到一模一樣的推薦。

const getRandomTrails = (arr, count = 3) => {
  const shuffled = [...arr].sort(() => 0.5 - Math.random());
  return shuffled.slice(0, count);
};

3. 收藏功能與狀態管理

收藏按鈕點擊後，依據使用者的「狀態」與「按鈕狀態」進行不同的流程處理：

1. 未登入：彈出 Toast 訊息提醒「請先登入才能收藏」，並延遲 1.5 秒自動跳轉至登入頁。
2. 已登入，未收藏：向伺服器發送 POST 請求，成功後更新收藏狀態，並彈出「收藏成功」Toast。
3. 已登入，已收藏：向伺服器發送 DELETE 請求，成功後解除收藏狀態，並彈出「已取消收藏」Toast。

4. Tag 標籤連動跳轉

步道詳細頁中包含多個分類 Tag。使用者點擊任一 Tag 時，會透過 React Router 帶著查詢參數跳轉到標籤頁，自動檢索並列出所有包含該標籤的步道。

5-3. 步道標籤頁 (TrailTag)

專門處理從詳細頁點擊 Tag 跳轉過來的檢索結果。

使用 useSearchParams 監聯網址上的 trail_tags 參數，當參數改變時觸發 useEffect 重新向 API 發送請求。

開發時遇到一個有趣的技術問題：trail_tags 欄位在 JSON 檔案中是陣列格式，而 json-server 的預設 query 語法無法正確比對。最終使用 _like 模糊查詢解決：

if (searchParams.get("trail_tags")) {
  const tagValue = searchParams.get("trail_tags");
  queryName = `trail_tags_like=${tagValue}`;
} else {
  queryName = searchParams.toString();
}

5-4. 404 頁面

當使用者輸入不存在的路由時，會導向設計友好的 404 頁面，搭配 Lottie 動畫，提供回到首頁的引導按鈕。

八、 專案心得與挑戰​

1. 組長角色的延續與深化​

這是我第二次擔任組長，延續上個專案驗證有效的 MVP 思維：先聚焦核心功能、確保準時上線，再評估加值功能。最終不只完成核心頁面，連原本列為選做的會員中心也順利上線。

這次團隊狀態比第一次複雜：原本一位組員因孩子受傷退出開發，另一位找到切版工作後時間變少，同時新加入一位有 UI/UX 經驗的前端。我在分工時讓對 React 還不熟悉的組員專注於切版任務，框架相關的問題則透過 AI 協作來補足。

到了專案中後期，我會主動 review 組員的 code，確認狀態管理的串接邏輯一致，也順手把部分重複的程式碼重構成可重用的元件。這個過程讓我從「只負責自己的頁面」變成「對整個專案結構有掌握度」，是這次組長角色最大的進化。

領導不是把所有事情扛起來，而是讓每個人都能在自己擅長的位置發揮。

2. AI 協作的個人方法論​

這次專案大量使用 AI 輔助開發，是我們能在 1~1.5 個月內完成的關鍵之一。我自己的習慣是先想好需求、再跟 AI 討論該用什麼語法或寫法比較合適，最後自己寫過一遍。

例如收藏功能的多狀態流程設計，我先把使用者狀態與對應行為釐清，再跟 AI 討論技術實作。又例如 ProtectedRoute 與 location.state 記住來源頁面，都是在我設定好需求後，請 AI 補上我還不熟悉的實作細節。

AI 給的是技術選項，但設計什麼樣的流程、解決什麼樣的問題，還是必須來自開發者自己的思考。

3. 跨領域探索：意外點燃對後端的興趣​

這個專案最意料之外的收穫，是因為要建置假資料 API 而踏進了後端的領域。實作過程中為了搭配登入驗證、處理部署環境的差異、理解 middleware 順序，逐漸接觸到 Node.js 的基礎知識。這段跨領域的探索結束後，我發現自己對後端的興趣比想像中強，因此後續報名了 Node.js 的課程。

4. 技術挑戰回顧​

• Promise.all 並行請求：原本三支 API 串行打的版本載入速度偏慢，改用 Promise.all 同時發出後首屏時間縮短不少。
• 收藏功能的狀態流程設計：在一個按鈕裡處理未登入 / 未收藏 / 已收藏三種狀態，是最複雜的互動設計。先把流程畫出來再寫程式，比直接動手寫快很多。
• JSON Server 陣列欄位查詢的小坑：標籤頁的 trail_tags 欄位是陣列，一般 query 抓不到資料，最終找到 _like 模糊查詢的解法。

寫 code 之前先把邏輯想清楚，可以省下很多 debug 時間。

5. 專題發表簡報​

• 🔗 20260301 專題發表簡報

一個以照顧者為核心的輔具資訊整合平台，希望透過友善的介面與清楚的分類，幫助家庭在長照旅程中更輕鬆地找到合適的輔具。

• Live Demo：伴你在日常
• GitHub：GitHub Repo
• 使用技術：Vite / Bootstrap 5 / SCSS / GSAP / Leaflet / Git / GitHub
• 團隊角色：組長 / 前端切版
• 專案管理：Notion / GitHub / Discord
• 專案時程：2025.07.01 ~ 2025.10.02
• 網站部署：GitHub Pages

一、 主題發想​

專題發想來自組員在護理現場的親身觀察。台灣長照輔具的資訊分散、專業術語多，許多家庭在第一次面對照顧需求時，光是選輔具就已經手足無措，找資料反而比照顧本身還累。

我們想做的不只是一個購物網站，而是一個讓照顧者真正用得上的平台——把複雜的輔具資訊整理清楚，用日常的語言說明用途，幫助家庭依照自己的環境與需求做出合適的選擇。品牌取名「伴你在日常」，也是希望這個平台能像一雙默默支持的手，陪著照顧者一起走過每一天。

二、 專案協作方式​

團隊使用 Notion 管理專案進度與文件，透過 Git / GitHub 進行版本控制與協作開發，並使用 Discord 保持日常溝通與討論，讓遠端協作也能維持一定的節奏與效率。此外，團隊每週也會安排約 2～3 小時的小組會議，進行進度同步、問題討論與工作分配，以提升整體協作效率與專案推進速度。

三、 使用者故事​

在規劃功能時，我們並非一開始就全部納入，而是考量到團隊成員同時在上課、每個人的時間與能力狀況不同，因此決定先確立核心頁面，再視情況延伸。最終確定的範圍包含首頁、關於我們、產品總覽、結帳頁面，以及原本列為選作的使用者頁面，後來由我負責並完整完成。

功能上我們依使用情境分為一般使用者與會員兩個層級：一般使用者可以瀏覽平台、依場景挑選商品、條件篩選與加入購物車，成為會員後則可以進入結帳、查看訂單、收藏商品與管理個人資料。

在設計過程中，我們也針對目標客群的使用情境進行思考，例如視力退化的長輩需要字體大、對比清楚的介面，家庭照顧者希望產品能依「使用場景」分類，不需要懂醫療術語也能快速找到所需商品。這些考量也實際影響了我們在頁面排版與分類方式上的決策。

四、 網站地圖與 Wireframe​

確認好功能範圍後，我們使用 Miro 繪製網站地圖，整理出各頁面之間的架構與跳轉關係，再依此產出 Wireframe，規劃每個頁面的版面配置與使用者操作流程。這個步驟幫助我們在正式開發前對整體結構有共同的認知，也減少了後期來回修改的成本。

• Miro Wireframe：伴你在日常 Wireframe

1. 網站地圖 (Site Map)​

清楚定義了使用者在網站中的瀏覽動線，區分出「一般使用者」與「會員」在操作路徑上的差異，確保整體架構沒有遺漏。

2. Wireframe (線框圖)​

將功能收斂成具體的畫面版塊，在正式進入設計前先確認好排版比例、按鈕位置與操作邏輯。

五、 UI 設計稿​

完成 Wireframe 後，我們邀請專業的 UI/UX 設計師依照架構進行視覺設計，產出完整的切版設計稿。有了設計稿作為依據，後續在切版與前端實作上也更有方向，能更準確地還原設計細節。

• Figma 設計稿：伴你在日常 UI 設計稿

六、 專案架構​

with_your_life/
├── assets/
│   ├── photo/               # 圖片資源（依頁面分類）
│   │   ├── index/           #   首頁用圖
│   │   ├── about/           #   關於頁用圖
│   │   ├── product/         #   商品頁用圖
│   │   ├── cart/            #   購物車頁用圖
│   │   ├── user/            #   會員頁用圖
│   │   ├── header/          #   Header 用圖
│   │   ├── footer/          #   Footer 用圖
│   │   └── logo-icon/       #   Logo 與 favicon
│   └── scss/                # SCSS 樣式檔
│       ├── all.scss          #   主入口，匯入所有模組
│       ├── base/             #   基礎樣式 (reset, typography)
│       ├── util/             #   變數、自定義 utilities
│       ├── layout/           #   Header / Footer 樣式
│       ├── pages/            #   各頁面專屬樣式
│       └── Component/        #   共用元件樣式
├── layout/                  # EJS 共用樣板
│   ├── header-loginIn.ejs    #   已登入狀態 Header
│   ├── header-loginOut.ejs   #   未登入狀態 Header
│   ├── footer.ejs            #   共用 Footer
│   └── link-icon.ejs         #   外部字體圖標引入
├── page/                    # 各頁面 HTML
│   ├── index.html            #   首頁
│   ├── about.html            #   關於我們
│   ├── product.html          #   商品列表
│   ├── cart.html             #   購物車
│   └── user.html             #   會員中心
├── main.js                  # 全域 JS 進入點
├── index.html               # Vite 根 HTML
├── vite.config.js           # Vite 設定檔
├── package.json             # 套件依賴與腳本
└── .gitignore               # Git 忽略規則

七、 個人負責開發項目​

進入開發階段後，我主要負責以下項目：

1. 專案基礎建置​

參考課程教材，動手設定專案的 Vite 建置環境，包含整合 EJS 樣板引擎、設定多頁面入口 (Multi-Page Application)、調整 build 後的輸出結構，以及配置 GitHub Pages 部署所需的 base 路徑。雖然部分設定是參考教材調整，但透過這次實作，對於前端建置工具與部署流程有了更實際的理解。

2. 全域變數設定​

透過 Bootstrap 5 的 Sass 變數客製化機制，覆寫框架預設的顏色、字型、間距等變數，建立符合品牌風格的統一樣式設定，讓團隊在切版時能維持一致的視覺風格，也方便後續維護與調整。

3. 導覽列 (Navbar)​

負責導覽列的切版與互動邏輯，並依登入前後切分為兩種狀態：

• 登入前：顯示「登入/註冊」按鈕，點擊後彈出 Bootstrap Modal，包含 Email 登入欄位、第三方登入選項 (Apple、Google、Facebook)，登入與註冊 Modal 之間也可互相切換。
• 登入後：將按鈕替換為「會員中心」下拉選單，整合訊息通知、我的收藏、訂單查詢、會員資料、登出等項目，並於購物車圖示加上未結帳商品數量的徽章 (badge)。

在響應式設計上，桌機版採水平展開的選單搭配下拉式子選單，手機版則改為漢堡選單搭配 Collapse 折疊式子選單。Logo 也使用 <picture> 搭配不同尺寸的圖檔，讓不同裝置都能載入合適的視覺資源。

4. 購物車頁面​

完成購物車頁面的切版與 RWD，依照設計稿還原版面細節。此頁面結構較為複雜，包含購物車商品列表、加購商品專區、配送與付款資訊、優惠折扣，以及即時計算的金額明細區塊。在響應式設計上，桌機版以表格形式呈現商品列表，手機版則改以卡片式版面呈現，讓不同裝置的使用者都能有良好的瀏覽體驗。

5. 使用者中心頁面（原專案選作項目）​

使用 Bootstrap 5 的 Tab 元件切換「我的訂單」、「收藏」、「個人資料」等分頁內容。為了讓使用者能從導覽列的下拉選單直接跳轉到指定分頁，我自行撰寫了一段 JS：監聽下拉選單的點擊事件、抓取連結中的 hash 值並存入 localStorage，搭配網址 hash 讓 Bootstrap Tab 自動切換至對應頁籤。

過程中也觀察到此功能在 Vite 開發環境下無法正常跳轉，但部署到正式環境後即可運作，是開發中印象深刻的除錯經驗。

八、專案心得與挑戰​

1. 第一次擔任組長的學習​

這份專題是我第一次擔任小組組長，也是第一次從零開始開發網站，過程中其實相當緊張，擔心無法順利完成。所幸組員們都很配合專案節奏，讓我們得以提早於預期時間內完成。

由於過去曾有 PM 的經歷，我在規劃開發流程時採用「最小可行性方案 (MVP)」的思維——先讓組員們收斂想法、完成各頁面的核心版面，並將想加入的動畫或進階效果以備註方式保留，等基礎版面完成後再自由發揮。這樣的做法不只讓專案能穩步推進，也降低了組員因方向不一致而產生的壓力。

2. 技術上的挑戰​

• Navbar 定位與 RWD：由於自己對於定位類型的切版還不熟悉，加上需同時符合響應式設計，實際做出來的版面與設計稿常有落差。當時我大量透過 AI 工具協作——把設計稿截圖貼上、描述問題，與 AI 一來一回討論寫法，逐步調整到接近設計的樣貌。這個過程也讓我學會如何更精準地提出技術問題、判斷建議是否合適。
• Tab 切換邏輯：當時對 JS 還不熟練，為了讓使用者能從導覽列直接跳轉到 user 頁面的指定分頁，自己嘗試寫出搭配 localStorage 與 hash 的解法。原本只是想讓切版作業更完整，意外成為這次專案中最有成就感的技術突破之一。

3. 學到的東西​

• 對 Bootstrap 5 的文件閱讀更熟練，也能善用其格線系統處理版面與 RWD。
• 對 Sass 變數客製化 有更深入的理解，能配合品牌規劃整體樣式。
• 學會如何 運用 AI 工具加速開發，例如釐清技術問題、討論切版寫法、debug。
• 在團隊協作中，學會用 MVP 思維 幫助大家收斂想法，讓專案能在有限時間內穩定推進。

4. 專題發表簡報​

• 20251003 專題發表簡報：簡報連結