前端 system design：從載入到上線的取捨清單

1. 面試不是背答案，是給思路 0:00–0:31

作者開場點出：要通過資深面試、要真的做好資深工作，都必須理解什麼是 system designi、怎麼做出可擴展的應用。他觀察到很多人在面試時「只是在回答問題」，對 senior 職位來說這樣不夠。這支影片要教的是怎麼回答 system design 問題，以及該講些什麼。

推理作者開場先把評分標準講清楚：他觀察到很多人在面試裡「只是在回答問題」，而這對 senior 職位不夠。因為如果評分標準是「答對」，準備方式就是背清單；他要先推翻這個假設，後面所有內容才有意義——他要教的不是清單，是怎麼講。

• R資深與中階面試回答的差別→ 存＋回想

AI 補充作者沒有明說「只是在回答問題」和「展現思路」差在哪，但這是整支影片的判準，值得先補上：回答問題是「有沒有這個東西」的是非題（「你會用 CDN 嗎？」「會」），展現思路是「在什麼條件下我選它、代價是什麼」的取捨題。面試官問 system design 通常沒有標準答案可對，他真正在觀察的是你會不會自己界定問題、會不會主動指出方案的缺點。這也解釋了為什麼同一份技術清單，中階講出來像背誦、資深講出來像決策紀錄。

術語:senior developeri

2. 前端 system design 是開放題 0:31–0:54

前端的 system design 沒有單一正確答案。面試官要看的是你怎麼思考：怎麼實作一個功能、一個專案，或怎麼把功能擴展出去。接下來作者要逐項談可擴展前端架構最重要的原則。

推理因為上一段把評分標準從「答對」換成「展現思考」，所以作者這裡必須先定義題型：前端 system design 是開放題，你要展示的是怎麼實作一個功能、一個專案，或怎麼把既有功能擴展出去。定義完題型，他才有立場宣布接下來要走一份「可擴展前端架構最重要的原則」清單——這份清單不是答案本身，是思考時可以掃描的面向。

AI 補充這裡有個容易被忽略的轉折：作者說沒有單一答案，卻馬上開始列清單，看起來矛盾。實際上清單的角色是「檢查面向」而不是「標準答案」——面試時你不會把十三項全講完，而是用它掃描哪幾項跟眼前這題的限制有關。值得注意他排清單的順序不是隨機的，而是跟著使用者的實際體驗走：先是程式碼怎麼送到瀏覽器，再來是送到之後怎麼跑、怎麼維持。用這個順序記，比按技術分類記更不容易漏。

術語:scalable architecturei

3. Bundling：把大檔切成 chunk 0:54–1:21

第一個一定要提的是 bundlingi。把整份前端 JavaScript 打包成單一檔案並不快，5 MB 以上的檔案載入太久。正解是 lazy loadingi：把巨大的 bundle 切成獨立 chunki，每個頁面只載入自己需要的那塊。

推理因為上一段決定要照「使用者實際遇到的順序」走，所以作者從 bundling 起手：把整份前端 JavaScript 打包成一個檔案並不快，5 MB 以上載入太久。他接著給出對應的解法——lazy loading 加上把大 bundle 切成獨立 chunk，每頁只載自己要的那塊。這一段建立了整支影片反覆出現的句型：先指出一個會隨規模惡化的問題，再給一個把「一整塊」拆成「按需要的小塊」的解法。

• CCode splitting：用動態 import 把大 bundle 切成獨立 chunk，每頁只載要用的那塊→ 畫地圖
• EReact.lazy(() => import('./Dashboard')) 讓 Dashboard 被單獨切成一個檔案→ 存＋演練
• P把自己專案裡最大的一個路由改成動態 import→ 練習

AI 補充投影片給的是 React.lazy 加動態 import 的兩行寫法，這裡值得補上它為什麼有效：`import('./Dashboard')` 這種動態語法在 build 階段就是給打包工具的切割記號，Vite 或 webpack 看到它就把 Dashboard 及其相依單獨輸出成一個檔案，執行期真的走到那一行才發請求。也就是說切割發生在建置期，決定要不要載發生在執行期，兩件事的分工要講清楚。另外作者的「5 MB」不必當成硬門檻——真正該看的是使用者在目標網路環境下等多久，行動網路上 1 MB 的 JavaScript 就足以讓首屏明顯變慢，因為 JS 除了下載還要解析和執行。實務上先切的通常是路由層級（每個頁面一個 chunk），再視情況切到元件層級（例如很少開的圖表或編輯器）。

術語:code splittingi

4. Micro-frontend：切團隊也切複雜度 1:21–1:56

第二點是 micro-frontendi：把前端應用拆成獨立部分，通常放進不同 repository，由不同團隊各自開發，彼此不互相干擾。代價是把這些部分接回去的複雜度變高。作者強調這只在專案夠大時才划算，幾個頁面的簡單應用不該這樣做。

推理因為 chunk 只解決載入量、解決不了「二十個人改同一份程式碼會互相踩腳」，所以作者接著提 micro-frontend：把前端應用拆成獨立部分，通常各自放進不同 repository，由不同團隊各自開發、互不干擾。他緊接著自己踩煞車——這樣做會提高把各部分接回去的複雜度，只有專案夠大才划算，幾個頁面的應用這樣做沒有意義。這個「先給好處再自己給代價」的動作，就是他第 1 段講的資深表現的示範。

• CMicro-frontend：把前端拆給不同團隊各自開發，是組織問題的技術解法→ 畫地圖

AI 補充投影片的架構圖把重點畫得很直接：一個 Shell Appi (host) 裡面放著 Search（A 團隊）、Recommendations（B 團隊）、Cart（C 團隊）。注意框線切的是團隊，不是技術層級——這是 micro-frontend 最容易被誤解的地方，它是一個組織問題的技術解法，不是效能最佳化手段。作者說「複雜度上升」但沒展開，實際的代價相當具體：共用的 React 版本必須協調（否則同一頁載入兩份 React），跨片段的路由與登入狀態要有共同約定，設計系統要抽成共用套件否則畫面會不一致，端對端測試要跨多個部署才跑得起來。判斷門檻可以用一個簡單問題代替「專案夠不夠大」：你們是否已經因為多個團隊搶同一條發布流程而互相等待？沒有這個痛，micro-frontend 買來的就只有成本。

5. Monorepo vs multi-repo 1:56–2:32

承接 micro-frontend 的追問：把前端拆到不同 repository 就是 multi-repoi；把所有模組放在同一個 repository 就是 monorepoi，可以用 Nxi 之類的工具管理。作者的重點不是名詞本身，而是資深工程師必須解釋「為什麼」以及兩者的差異。

推理因為拆開之後 repository 的擺法變成一個真的要選的問題，所以作者把兩個選項並排：拆到不同 repository 是 multi-repo，全部模組放在同一個 repository 是 monorepo，可以用 Nx 這類工具管理。然後他把這一段的重點從技術拉回第 1 段的判準——資深工程師必須解釋為什麼以及兩者差在哪，而不是只報出這兩個名詞存在。

• RMonorepo 與 multi-repo 的核心取捨→ 存＋回想

AI 補充投影片的對照表比口述多給了關鍵的一筆：multi-repo 那一欄標了 versioning hell，並附上實際流程——app-a 要修 shared-ui 的 bug，得開 PR、等發版、升版號，要花好幾天；monorepo 則是一個 PR 就解決。這句註解才是真正的取捨核心：multi-repo 換來的是團隊自主，付出的是跨套件改動的延遲；monorepo 換來的是一次改完，付出的是共用一條 CI、共用工具鏈，以及需要 Nx／Turborepo 這類工具做增量建置，否則改一行就全部重跑。要注意 monorepo 和 micro-frontend（見第 4 段）是兩個獨立的軸，可以自由組合：monorepo 裡放多個可獨立部署的片段是很常見的組合，同一份程式碼庫、各自的發布流程。作者這裡口語上把 monorepo 說成了「monolith versus multi-repo」，看投影片就知道他要對比的是 monorepo。

6. Module federation：各自部署 2:32–2:55

第二個追問是 module federationi——把前端切成不同片段、之後在單一專案裡載入的具體機制。關鍵好處是 A 團隊可以部署自己那塊的新版本，主應用會直接吃到新版，不需要所有片段一起重新部署。

推理因為 repository 的擺法決定不了執行期怎麼合體，所以作者把 module federation 當成第二個追問端出來：它正是把前端切成不同片段、之後在單一專案裡載入的方式。他把價值濃縮成一句——A 團隊可以部署自己那塊的新版本，主應用會直接吃到，不必所有片段一起重新部署。這句話正好兌現了第 4 段承諾的「互不干擾」：如果每次改動都要一起發版，拆開就沒有意義。

• CModule federation：host 只記路徑，執行期才去別的團隊抓最新版模組→ 畫地圖
• Amodule federation 像不打包的相依：host 只記路徑，執行期才去抓→ 批判類比
• Ewebpack remotes 設定：cart: 'cart@https://cdn.team-b.com/remoteEntry.js'→ 存＋演練

AI 補充投影片的 webpack 設定把機制講得比口述清楚：host 的 `remotes` 裡寫著 `cart: 'cart@https://cdn.team-b.com/remoteEntryi.js'`，接著在 React 程式碼裡用 `React.lazy(() => import('cart/CartWidget'))` 使用它。關鍵在那個 URL——host 在建置時並不打包 cart 的程式碼，只記下去哪裡拿；執行期才抓 remoteEntry.js，那是一份 B 團隊產出的清單，說明有哪些模組、實際檔案在哪。所以 B 團隊重新部署、覆蓋掉那個 URL 的內容，host 下一次載入就自動拿到新版，完全不用重 build。注意這裡重複用到了第 3 段的 `React.lazy` 動態 import：同一個語法，先前切的是自家的 chunk，現在跨過網路邊界去拿別人的模組。代價也在同一個地方——那個 URL 掛掉或版本不相容時，host 就開天窗，而且 React 這類共用相依必須在 `shared` 設定裡協調好，否則同一頁會載入兩份。

7. CDN 與快取：距離就是延遲 2:55–3:36

接著是 CDNi 與 caching。作者用具體數字說明價值：沒有 CDN 時，東京的使用者要打到美國的 origin serveri，大約 200 毫秒；配好 CDN 後從東京當地節點、甚至直接從快取拿，只要幾十毫秒。追問則是資產要快取多久、什麼時候要讓快取失效i。

推理因為前面幾段產出的所有檔案（chunk、remoteEntry、各片段的程式碼）都得跨網路送到使用者手上，所以作者把 CDN 與快取拉成獨立一項，並且用數字說服：沒有 CDN 時東京的使用者要打到美國的 origin server，大約 200 毫秒；配好 CDN 之後從東京當地節點、甚至直接命中快取，就只要很短的時間。接著他照慣例給出追問——資產要快取多久、什麼時候要讓它失效。

• CCache invalidation：帶內容雜湊的檔案長快取，指路的入口檔要短快取→ 畫地圖
• Echunk 檔名帶內容雜湊可設超長快取，index.html 與 remoteEntry.js 要設極短快取→ 存＋演練
• RCDN 為什麼能把延遲從等比降到很低→ 存＋回想

AI 補充投影片把兩條路徑並排畫出來，數字是 Tokyo → Virginia 約 200ms、Tokyo → Edge nodei 命中快取約 20ms。這裡值得補一個作者跳過的因果：延遲的主因不是伺服器慢，而是光速加上 TCP／TLS 的來回次數——距離愈遠，每一次握手都要多花一趟往返，所以縮短物理距離的收益是成倍的，不是線性的。至於他留下的追問，實務上的標準答案是把資產分成兩類：帶內容雜湊的檔名（見第 3 段的 chunk 命名）可以設超長快取，因為內容一變檔名就變；而 index.html 與第 6 段的 remoteEntry.js 這種「指路的檔案」必須設極短快取或不快取，否則使用者會拿著舊地圖去找新檔案。這個組合就是「不可變資產長快取 + 入口檔短快取」，也是為什麼快取失效在前端多半靠檔名而不是靠手動清 CDN。

8. Bundle 最佳化與瀏覽器載入順序 3:36–4:21

再來是 bundle 最佳化。tree shakingi 能砍掉沒用到的函式，但前提是 import 寫對——某些寫法會把整個函式庫拉進來，這個好處就沒了；要查問題可以用 webpack bundle analyzeri。第二點是理解瀏覽器怎麼執行 JS 與 CSS、何時 paint 與 repaint，所以要懂 deferi 之類的手段；作者看過很多正式環境的 script 互相擋住彼此。

推理因為距離已經不是瓶頸，所以作者把注意力轉回檔案內部，講兩件事。第一是 tree shaking：它能砍掉函式庫裡沒用到的函式，但前提是 import 寫對，某些寫法會把整包拉進來、好處就沒了；要查有沒有中招可以用 webpack bundle analyzer。第二是瀏覽器怎麼執行 JS 與 CSS、何時 paint 與 repaint，所以要懂 defer 之類的手段——他說他在正式環境看過大量 script 互相擋住彼此的案例。

• CTree shaking：砍掉沒用到的函式，但 import 寫錯就整包被拉進來、無警告→ 畫地圖
• E同一個 debounce，三種 import 寫法差 70KB+、2KB、可完全搖掉→ 存＋演練
• Rdefer／async 只對外部 script 有效→ 存＋回想

AI 補充兩張投影片把這段變得可操作。第一張把同一個 `debounce` 的三種寫法並排：`import _ from 'lodash'` 會拉進整包（70KB+），`import debounce from 'lodash/debounce'` 只有 2KB，`import { debounce } from 'lodash-es'` 則因為是 ES module 格式而能被正確搖掉。原因作者沒說：tree shaking 靠的是 ES module 的靜態結構分析，CommonJS 的 `require` 在執行期才決定拿什麼，工具無從判斷哪些能刪——所以 lodash（CommonJS）要靠子路徑 import，lodash-es 才能享受具名 import。第二張則列出四種 script 寫法：無屬性會擋住解析與繪製、`defer` 平行下載並在 HTML 解析完後依序執行、`async` 下載完立刻執行（適合彼此無關的第三方腳本）、critical CSS 直接內嵌以免首屏等外部樣式檔。這正是他說的「script 互相擋住」的解法清單。順帶一提：`defer`／`async` 只對外部 script 有效，寫在內嵌 script 上不會生效，這是實務上很常見的誤用。

術語:render blockingi

9. State management：三種 state 4:21–5:06

狀態管理的重點是分清楚三種 state：global app state、server statei、client state，以及各自該用什麼工具。從 API 拿來的 server state 用 React Queryi 這類函式庫；全域 UI state 可以用 Redux；區域 state 用 useState 就夠。作者提醒要挑適合該業務的工具，很多專案只用 React Query、寫最少的程式碼就夠了。

推理因為前面所有段落談的都是「把程式碼送到瀏覽器」，到這裡主題正式轉入 runtime，所以作者先給分類再給工具：要分清楚 global app state、server state 與 client state，並知道各自該用什麼。從 API 拿來的 server state 用 React Query 這類函式庫，全域 UI state 用 Redux，區域 state 用 useState 就夠。他隨即補上和第 4 段同一種煞車——要挑適合該業務的工具，很多專案只用 React Query、寫最少的程式碼就夠了。

• CServer state：手上永遠只是伺服器資料的一份副本，可能過期→ 畫地圖
• Aserver state 就像快取：本地存的是可能過期的副本，真相在遠端→ 批判類比
• E早年常見錯誤：把 API 資料塞進 Redux，自己寫 loading／error／重新抓取→ 存＋演練
• P檢查自己專案有沒有把 API 資料錯塞進全域 store→ 練習

AI 補充投影片的三列表格把分類講得比口述完整：Server State 是 API 來的資料，用 React Query 或 SWR；Global UI Statei 是 auth、主題、sidebar 開關，用 Zustand 或 Redux；Local UI Statei 是 modal 開關、輸入框的值，用 useState。這個分類真正的價值在於指出一個歷史誤區：早年大家把 API 資料也塞進 Redux，於是要自己寫 loading、error、快取、重新抓取、race condition 處理——而這些全都是 server state 特有的問題，因為那份資料的真正來源在別人的伺服器上，你手上的永遠只是一份可能過期的副本。React Query 這類工具存在的意義就是把「副本管理」標準化。反過來說，真正的 UI 狀態（modal 開不開）沒有這些問題，用 useState 就夠，硬塞進全域 store 只會製造樣板程式碼。判斷方式很簡單：這份資料的真相在伺服器上，還是只存在於這個瀏覽器分頁裡？

10. 即時同步與斷線後怎麼辦 5:06–5:36

延伸出來的是即時同步、WebSocketi 與 Socket.IOi，因為現在很多專案有通知、協作共享、即時儀表板。作者示範可以自己延伸的追問：連線斷掉時你怎麼做？重播漏掉的事件，還是整份重新抓？答案取決於專案需求。

推理因為「去拉」的模型撐不住通知、協作共享與即時儀表板這些現在很常見的需求，所以作者把即時同步、WebSocket 與 Socket.IO 拉出來講。他接著做了一個很值得學的動作：不是等面試官問，而是示範你可以自己延伸的追問——連線斷掉時你怎麼做，重播漏掉的事件還是整份重新抓？然後回到他的標準答案形狀：看專案需求。

• CEvent replay：斷線重連補回漏掉的事件，適合每個事件本身有意義的場景→ 畫地圖
• R重連時要用指數退避→ 存＋回想

AI 補充投影片直接把這兩個追問寫成一張 QUESTIONS 清單，等於在告訴你：這是可以主動端上桌的問題。作者沒說的是這兩條路各自的代價，而這才是面試裡真正能得分的部分。重播（replay）需要伺服器保留事件序號與一段歷史，客戶端重連時帶上最後收到的序號、把缺口補回來——聊天訊息或協作編輯適合這條，因為每個事件本身有意義、漏掉就是資料不見。整份重抓（refetch from scratch）簡單得多，只要重新載入當前快照即可——即時儀表板、股價、線上人數適合這條，因為你只在乎最新值，中間漏掉的舊值本來就沒用。判斷方式其實接得上第 9 段的問題：這些推送是「事件」還是「最新狀態」？另外補一個作者沒提但實務必備的細節：重連要用指數退避，否則伺服器一掛，成千上萬的客戶端會同時重連把它再打掛一次。

術語:event replayi

11. CI、feature flag 與 A/B 測試 5:36–6:15

基礎建設與部署也要談：每次有人開 pull requesti，CIi 就要跑 lint、測試與 build，這樣合併前大家才確定程式碼被檢查過。另一項是 feature flags 與 A/B testingi——業務常需要漸進推出新功能，或比較哪個版本比較受使用者歡迎，資深工程師必須會實作。

推理因為前面所有設計都要靠一條可靠的發布流程才落得了地，所以作者把基礎建設與部署列進來：每次有人開 pull request，CI 就要跑 lint、測試與 build，這樣合併前大家才確定程式碼被檢查過。接著他把「安全上線」再往前推一步——feature flags 與 A/B testing：業務常需要漸進推出新功能，或比較哪個版本比較受歡迎，資深工程師必須會實作。

• CFeature flag：讓部署與發布脫鉤，程式碼先合併但對使用者關著→ 畫地圖
• Rfeature flag 的隱藏代價→ 存＋回想

AI 補充第一張投影片把口述的三件事展開成一份 ci.yml 的七個步驟：`npm ci`（用 lockfile 安裝並吃快取）、lint、type-check、單元測試、build、e2e、以及 lighthouse 效能預算。最後那項特別值得注意——它把第 3 段和第 8 段談的載入效能變成 CI 會擋下來的硬指標，否則 bundle 的體積只會隨著時間單向惡化，沒有人會主動回頭修。第二張是 YouTube 後台的 A/B 測試報告：三個縮圖標題的觀看時間佔比（23.5%、43.3%、33.2%）與 winner 標記，這是他自己頻道的真實數據。這裡有個作者沒點破但很重要的關聯：feature flagi 讓「部署」和「發布」脫鉤——程式碼可以先合併進 main 並部署，但對使用者關著，要開給誰、開多少比例是執行期的決定。這正好解決了第 4 段 micro-frontend 的一個隱憂：獨立部署要能獨立回退，而 flag 就是不用重新部署也能立刻關掉某功能的開關。代價是每個 flag 都是一條分支，清不掉的舊 flag 會讓程式碼難以推理，所以實務上要給 flag 設定到期日。

12. 可靠性：不要整頁白畫面 6:15–6:42

再來是可靠性：程式要能扛住錯誤，不能讓整頁掛掉。要攔截失敗、提供 fallback，而不是給使用者一片白畫面。而且正式環境一定會出 bug，所以需要能顯示 bug 發生、怎麼重現、stack tracei、效能與使用者行為的工具。

推理因為上線流程再嚴謹也擋不住所有錯誤，所以作者把可靠性當成最後一項技術主題：程式要能扛住失敗，不能讓整頁掛掉——要攔截失敗並給出 fallback，而不是丟給使用者一片白畫面。而且既然正式環境一定會出 bug，就需要能顯示 bug 發生、怎麼重現、stack trace、效能與使用者行為的工具。這兩句話對應到兩個動作：先撐住畫面，再收集足夠修好它的資訊。

• CError boundary：攔截渲染錯誤切到 fallback，讓一塊壞掉不拖垮整頁→ 畫地圖
• A每個 micro-frontend 包一層 ErrorBoundary，像電路的保險絲→ 批判類比
• EgetDerivedStateFromError 切 fallback，componentDidCatch 把錯誤連 userId／route 送去監控→ 存＋演練
• P替專案裡一個容易出錯的區塊加上 ErrorBoundary→ 練習
• RErrorBoundary 攔不到的錯誤類型→ 存＋回想

AI 補充兩張投影片分別對應這兩個動作。第一張是 ErrorBoundary 的完整實作：`getDerivedStateFromError` 把畫面切換成 fallback、`componentDidCatch` 把錯誤送去監控服務，fallback 的文案寫的是「這一區塊載入失敗，頁面其他部分仍可使用」。最關鍵的是最後那行註解——每個 micro-frontend 各包一層 ErrorBoundary，這把可靠性直接接回了第 4 段的架構：既然各片段獨立部署，就必須獨立失敗，否則 B 團隊的一次壞部署會讓整站白畫面，獨立部署反而放大了風險。第二張是監控端：`unhandledrejection` 事件帶上 userId 與 route 一起回報，加上 PerformanceObserver 收集 LCP 與 layout-shift。這裡的重點是那行註解說的——有上下文（誰、在哪一頁）的錯誤報告才可能重現，只有一行 stack trace 的報告通常修不了。要補充的是 ErrorBoundary 的邊界：它只攔得到 React 渲染期間的錯誤，攔不到事件處理器裡、非同步回呼裡與 Promise rejection 的錯誤——後者正是第二張投影片用全域監聽補上的那一塊。兩者是互補的，不是二選一。

術語:error boundaryifallback UIiCore Web Vitalsi

13. 先問限制，再提方案 6:42–7:12

作者的收尾結論：資深工程師在面試裡最重要的不是先丟出解法，而是先問限制——業務到底要什麼、現在已經有什麼、我們實際上在解什麼問題。最後導向他的 middle to senior 前端訓練營。

推理因為前面每一段都以「這要看情況／要看專案需求」收尾，所以作者在這裡把那個反覆出現的但書提升成整支影片的結論：資深工程師在面試裡最重要的不是先提出解法，而是先問限制——業務到底需要什麼、現在已經有什麼、我們實際上在解什麼問題。這正好閉合了第 1 段的開場：如果評的是思路而不是答案，那麼最能展現思路的一步，就是先證明你會界定問題。最後他把觀眾導向自己的中階到資深前端訓練營。

• CConstraints：先問規模、現況與真正要解的問題，才有依據做每個技術選擇→ 畫地圖

AI 補充這個收尾值得多花一點力氣理解，因為它是整支影片唯一可以直接照做的行為準則。前面每一項技術都附帶一個「什麼時候不該用」——micro-frontend 在小專案是純成本、Redux 在單純的 UI 狀態是樣板、CDN 對個人化內容有風險——這些但書全都指向同一件事：沒有限制條件i，就沒有正確答案。所以先問限制不是禮貌，而是取捨的前提。實務上這三個問題可以直接照用：規模與限制是什麼（多少使用者、什麼裝置與網路、團隊幾人、要多快上線）、現況是什麼（既有技術棧、既有痛點）、以及真正要解的問題是什麼（業務指標是轉換率、留存還是開發速度）。問完之後你講的每個技術選擇都有依據，而不是在報名詞——這就是第 1 段說的「只是在回答問題」與展現思路之間的全部差距。