最近有在美國讀書的同學(xué)來問我 Meta（Facebook 的母公司）的前端面試情況，特別是傳說中的 系統(tǒng)設(shè)計題（System Design） 到底應(yīng)該怎么回答。

國外大廠（FAANG：Facebook、Apple、Amazon、Netflix、Google）和國內(nèi)大廠在前端面試上，有著非常明顯的差別。

國內(nèi)的面試更多聚焦在代碼能力與項目細(xì)節(jié)上，比如：框架原理、性能優(yōu)化、跨端、工程化、埋點、打包優(yōu)化這些。

但是，在歐美那邊，以 FAANG 這些公司為首的大廠，面試時會更加看重你能否從產(chǎn)品功能的角度，去設(shè)計一整套完整的系統(tǒng)架構(gòu)。也就是傳說中的 系統(tǒng)設(shè)計題（System Design）。

System Design 不是讓你寫具體代碼，而是要你設(shè)計一個完整可運行的前端系統(tǒng)。

比如，面試官通常會這樣出題：“請你設(shè)計一個新聞流 / 帖子流 / 聊天系統(tǒng) / 實時協(xié)作文檔......”

聽起來有點像國內(nèi)的代碼題，但是實際上卻完全不同。

這類問題需要你從：

• 數(shù)據(jù)結(jié)構(gòu)怎么設(shè)計？
• 怎么分頁、緩存、實時更新？
• 性能、可擴展性、錯誤恢復(fù)怎么保證？

等多個系統(tǒng)設(shè)計角度來回答才可以。而不是單純的寫個 demo 就完事的。所以 System Design 一直是很多同學(xué)面試國外大廠的 “掛點...”。

不過，雖然 FAANG 這些大廠的面試很難，但是它們給出來的薪資還是相當(dāng)香的。并且國外很多互聯(lián)網(wǎng)大廠都是帶股票的，通常情況下 職級越高，股票在薪資中占的比重就會越大。

就以 Meta 為例。

在 Meta，前端崗位屬于軟件工程師體系（Software Engineer），采用的是 E 序列職級，從 E3 → E9 依次遞進(jìn)。

下面是根據(jù) Levels.fyi（美國地區(qū)）與訓(xùn)練營海外同學(xué)整理的數(shù)據(jù)：

根據(jù)薪資水平咱們可以看到，哪怕是 E3 → E5（同比阿里 P5~P7 職級） 年包薪資也在 130 萬 ~ 370 萬人民幣 之間了。這個薪資放到國內(nèi)，妥妥的頂級大佬水平了...

所以，面試難點，咱們也就忍了 ????

那接下來，我們就來看一看這道在 Meta 幾乎每年都必考的題目：請你設(shè)計一個 Facebook 的帖子流（News Feed）。

請你設(shè)計一個 Facebook 的帖子流（News Feed）

這是一個特別典型的 系統(tǒng)設(shè)計題（System Design），真正要答好它，你至少得考慮到以下這些方面：

1. 數(shù)據(jù)層設(shè)計

• 帖子（Post）結(jié)構(gòu)如何定義？
• 評論、點贊要不要單獨拆表？
• 如何支持分頁、增量更新？

2. 前端渲染性能

• 當(dāng)頁面有上千條帖子時，怎么避免卡頓？
• 是否需要虛擬滾動（Virtual List）？
• 圖片、視頻如何懶加載？

3. 實時性與交互

• 新帖來了怎么實時刷新？
• 點贊、評論如何做到局部更新而不重渲染整個頁面？
• WebSocket / SSE 怎么選擇？

4. 狀態(tài)管理與擴展性

• 狀態(tài)放全局（Store）還是局部（組件）？
• 如何支持“多端一致”（Web + App）？

5. 用戶體驗與容錯

• 網(wǎng)絡(luò)慢怎么辦？
• 出錯時如何降級？
• 有沒有骨架屏、預(yù)加載機制？

是不是看著有點復(fù)雜了，方方面面都得考慮到。

那下面咱們就一起拆解下這個問題哈：

一、數(shù)據(jù)層設(shè)計：Feed 數(shù)據(jù)結(jié)構(gòu)與分頁機制

先從最底層的數(shù)據(jù)說起。

每條帖子（Post）包含：作者、內(nèi)容、媒體、點贊、評論、時間戳等信息：

{
  id: 'post_123',
  author: { id: 'u1', name: 'Sunday', avatar: 'a.jpg' },
  content: '今天寫了一篇公眾號 ??',
  media: ['img1.jpg', 'img2.jpg'],
  likes: 230,
  comments: 58,
  createdAt: 1730098800000
}

分頁機制：

• 采用 Cursor-based Pagination（基于游標(biāo)的分頁），而非傳統(tǒng)的 page=1,2,3。
• 這樣能避免用戶在動態(tài)內(nèi)容頻繁變化時，翻頁數(shù)據(jù)重復(fù)或錯亂。
• 例如后端返回：

{
  data: [...posts],
  nextCursor: "1730098800000"
}

評論與點贊延遲加載（Lazy Load）：首屏只加載主要內(nèi)容，評論區(qū)按需請求，提升初始渲染速度。

二、渲染層設(shè)計：虛擬滾動 + 懶加載

新聞流頁面的最大問題是 內(nèi)容太多。 如果直接一次性渲染上百條帖子，DOM 數(shù)量會非常龐大，性能必崩。

解決方案：虛擬列表（Virtual List）

核心邏輯是：

• 只渲染可視區(qū)域的帖子；
• 滾動時動態(tài)替換上、下區(qū)域的內(nèi)容。

const observer = new IntersectionObserver(loadMore)
observer.observe(document.querySelector('#bottom'))

再加上：

• 圖片懶加載 <img loading="lazy">
• 視頻延遲播放（進(jìn)入視口才加載）
• Skeleton（骨架屏） 讓用戶視覺上更流暢

三、通信層設(shè)計：實時更新（WebSocket / SSE）

Facebook 的帖子流是實時的。 有人點贊、評論、發(fā)新帖，用戶的頁面就要自動更新。

在前端層面，有兩種常見做法：

示例：

const ws = new WebSocket('wss://meta.com/feed')
ws.onmessage = (event) => {
  const newPost = JSON.parse(event.data)
  feedStore.add(newPost)
}

建議答題時提到：“我會用 SSE 或 WebSocket 實現(xiàn)增量推送，同時配合時間戳去重機制，確保狀態(tài)一致?！?/span>

四、狀態(tài)層設(shè)計：全局 Store + 局部更新

系統(tǒng)設(shè)計題中，狀態(tài)管理是高頻考點。

如果你直接用 setState(posts) 更新整個列表，那每次點贊、評論都會導(dǎo)致整個頁面重渲染，這在 Meta 面試中是大忌。

正確做法是：

const feedStore = createStore({
  posts: [],
  updatePost(id, patch) {
    this.posts = this.posts.map(p => p.id === id ? { ...p, ...patch } : p)
  }
})

同時利用：

• 不可變數(shù)據(jù)結(jié)構(gòu)（Immutable） 保證更新粒度
• Diff 策略 避免全量渲染
• 局部更新 提升交互體驗

五、性能與容錯設(shè)計

這類題最后 90% 的候選人都會被問到一個問題：

“如果帖子有幾千條，網(wǎng)絡(luò)又慢，該怎么辦？”

這個時候就會回答對應(yīng)的 “架構(gòu)思維” 了：

• 首屏 SSR：讓用戶快速看到內(nèi)容框架（減少白屏）
• Skeleton 骨架屏：增強加載感知
• 請求合并 + 緩存策略：減少重復(fù)接口
• 指數(shù)退避（Exponential Backoff）重試機制：提高容錯率
• CDN 緩存圖片與視頻：減輕服務(wù)器壓力