模組六｜SEO/SSR（Day 25–28）
先備：Day 25–27（SSR 光譜、爬蟲實測、三帖補救藥）。這一篇可以單獨帶進選型會議，但每一格的理由都在前三天。
這個標題其實一個字就能答完：「不。」但只答這個字有兩個問題——第一，這篇會變廢文；第二，世界上存在一整批專案，這個問題對它們根本不成立，而分辨出「你的專案是不是那批」才是選型會議上真正值錢的能力。今天把 Day 25–27 的證據壓成一個可以直接帶進會議的框架。
結論先講：
SEO 是不是核心需求，這個問題要在選框架之前問，不是之後。
因為 Day 27 那三帖藥全部是體外循環——它們能止痛，但沒有一帖能把「內容不在 DOM 裡」這件事改掉。
先定錨：Vue 陣營對 SEO 導向專案的答案是一條完整光譜。Nuxt 的 routeRules 讓 SSR、SSG、ISR、CSR 在同一個專案裡按路由混用，內容頁全靜態、商品頁增量再生、後台純 CSR——全是設定檔等級的決策（Day 25）。爬蟲在第一關就拿到完整 HTML，路由級 meta 是框架原生功能（Day 26 的 useSeoMeta）。
所以框架的第零條是：當 SEO 是核心需求，Vue/Nuxt 是預設解，舉證責任在想換掉它的人身上。 這不是信仰，是這三天的技術盤點結果。
Day 1 我給過一棵決策樹，走到 Day 28，它經過了 SEO 專題的完整檢驗，維持原判：
疊上 SEO 維度後，關鍵的前置問題是：SEO 對這個產品是收入管道，還是虛榮指標？ 內容站、電商，自然流量就是命脈，落入分支 3，討論結束。但登入牆後的工具型產品，「SEO 需求」實際上只是一頁 landing page——那用 Day 27 的混合架構就打發了：Nuxt 寫官網，Flutter 寫 app。
function shouldUseFlutterWeb(project) {
// 第一題是否決題，先刷掉，後面兩題不必跑
if (project.seoIsRevenue) return 'NO —— 分支 3，回去用 Vue/Nuxt'
if (project.hasFlutterMobileApp) return 'YES —— 分支 1，唯一強理由'
if (project.isCanvasHeavy) return 'MAYBE —— 分支 2，往下看正面案例'
return 'NO —— 分支 3，回去用 Vue/Nuxt'
}
注意 seoIsRevenue 的守衛擺在最前面，而不是塞在分支 2 的條件裡：就算你已經有 Flutter mobile app，只要 SEO 是收入管道，答案還是不要——那個情境的正解是 Day 27 的混合架構（Nuxt 寫官網、Flutter 寫 app），不是「因為有 app 可以複用所以整站給 Flutter」。這個守衛的位置，就是整個框架最容易被說服放棄的一行。
分支 2 不是空集合。看盤／交易介面是它的教科書場景，五個條件全中：
加分項：這類產品幾乎都有 mobile app 需求（看盤 app 是標配），等於同時命中分支 1——跨平台複用在這裡是真實收益，不是簡報上的口號。這也解釋了為什麼市面上真的存在用 Flutter 打造的看盤產品，這個分支不是紙上談兵。
反面清單也要誠實列：文字選取、複製報價、無障礙、i18n 排版都是模擬行為；如果產品含大量表格式資料頁（財報、公告），那部分仍該留給 DOM——用 Day 27 的 element embedding 切給 Nuxt 做。結論：看盤軟體是「Flutter Web 該不該用」這個問題的最佳反例——在這一格，它不只是能用，而且可能比 Vue 更順。這種場景很少，但它真的存在，所以第零條的舉證責任才有意義：舉證責任存在，代表舉得出來的人可以贏。
框架要有用，得先能判自己。把 Waypoint Air 的兩個版本丟進去跑一遍：
它是一個訂票流程——選日期、選人數、選航班、確認、付款。沒有內容頁、沒有商品目錄、沒有部落格，全部畫面都在使用者「開始訂票」之後才有意義。如果它是真產品，SEO 需求會落在哪裡？ 落在首頁跟航線介紹頁，而那兩頁在我的 demo 裡根本不存在。
所以誠實的判定是：這支 demo 落在分支 2 的邊緣——工具型、流程導向、SEO 需求集中在少數幾個入口頁。真要上線，我會照 Day 27 的第三帖走混合架構：首頁和航線頁用 Nuxt，訂票流程從 /booking 開始交給 Flutter。
而它現在的樣子（Day 26 那兩個樣板值、vercel.json 只有一條 rewrite）說明了另一件事：這兩個 demo 從來沒有為 SEO 做過任何準備，而我到 Day 26 才發現這件事。 這正是這個框架要防的事——SEO 不是上線前的檢查項，是選型當下的輸入。
坑一：拿「Googlebot 會跑 JS」替 Flutter Web 辯護。 Day 26 驗過屍了——跑完 JS 看到的是一張圖，這個論點在 Flutter Web 上連部分成立都談不上。症狀：會議上有人講完這句，全場就過了；三個月後 Search Console 顯示產品頁全部「已檢索，尚未建立索引」。
坑二：把混合架構當免費附件。 它救得了 SEO，但兩棧並養的組織成本是真的（Day 27），評估時要進成本欄，不要放備註欄。症狀：專案排程時「加一層 Nuxt 做行銷頁」被估成兩週，實際上光是把設計系統在兩邊對齊就花掉一個月。
坑三：SEO 需求會長出來。 這是最陰險的一個。產品從工具 pivot 成內容平台、行銷說要開部落格養自然流量——Vue 專案加個 Nuxt 就有逃生門，Flutter Web 沒有。選它等於對「這個產品未來不需要 SEO」下注，下注前請確認賠率。症狀：兩年後行銷部門要求做內容行銷，工程給出的評估是「等於再開一個新專案」，而當初的選型會議紀錄裡沒有任何人提過這個風險。
坑四：選型錯誤是雙向的。 反過來，看盤類產品硬用 DOM 去畫 tick 級圖表，是另一種效能地獄。框架的意義不在護航某個陣營，在讓兩種錯都犯不下去。症狀：報價一秒跳十次，你在 DevTools 看到 layout thrashing 警告排滿整頁，而那個元件已經被三個人各自最佳化過一輪了。
坑五：框架要當會議議程跑，不要當結論貼。 順序很重要。決策樹告訴你「落在哪一格」，但會議上你真正需要的是「多快能刷掉不用討論的選項」——所以實際開會請照這三個問題跑，跑完才對照決策樹。症狀：你把決策樹貼在簡報第三頁，會議上大家看完點頭，然後花四十分鐘討論「可是我們團隊比較熟哪個框架」——因為那張圖回答的是結論，沒有回答「哪些選項現在就可以不用討論」。
三個問題是：
順序不能換，第一題一定最先問，理由是它最殘酷也最快：一旦答案是「要靠搜尋」，後面兩題連做都不用做，會議可以直接進下一個議程。反過來先問「我們有沒有 mobile app 可以複用」，等於讓一個注定出局的專案先跑完一輪加分題，開一小時得到一個第一分鐘就該有的結論。而順序整個反過來的選型會——先選好想用的框架、再回頭找理由——結論通常在投影片做完之前就內定了，這三天的所有證據都會被當成雜訊。
一句話：SEO 導向專案選 Flutter Web 的答案是「不要」，而真正的專業是在會議上分辨出你的專案到底是不是 SEO 導向——看盤軟體就不是。明天 Day 29〈生態系與工具鏈踩坑心得：套件成熟度盤點＋DevTools 除錯實戰〉，從一個問題開場：畫在 canvas 上，那 console.log 去哪了？
如果你卡在語法
深入原理
iThome鐵人賽
看影片追技術