速查表 (Quick Reference)

面試預設選擇

網路層次 → 網路層次與請求流程

Web 請求流程：DNS 解析 → TCP 三次握手 → HTTP 請求 → 伺服器處理 → HTTP 回應 → TCP 四次揮手

TCP vs UDP → 傳輸層協定 TCP vs UDP

瀏覽器只能透過 WebRTC 使用 UDP。

HTTP 方法與狀態碼 → HTTP 與 HTTPS

API 範式 → API 範式比較、API 設計決策框架

策略：內部 gRPC + 外部 REST

決策樹：

External or Internal?
├── Internal ────────────► RPC / gRPC
└── External
     └── Over/Under-fetching concern?
          ├── Yes ─────► GraphQL
          └── No  ─────► REST

即時通訊 → 即時通訊協定

決策：SSE 夠嗎？→ 需要雙向？→ WebSocket → 需要 P2P 音視訊？→ WebRTC

負載平衡 → 負載平衡

演算法：無狀態 → Round Robin；長連線 → Least Connections；Session 持久 → IP Hash

降低延遲：靜態內容 → CDN；地理相關資料 → 區域分片

故障處理模式 → 故障處理模式

熔斷器狀態機：

Closed ──失敗超閾值──► Open ──逾時到期──► Half-Open
  ▲                                        │
  └──────── 測試成功 ──────────────────────┘
                        測試失敗 → 回到 Open

Client-Server Architecture → 主從架構

Thin Client（SSR）vs Thick Client（SPA/App）— 現代預設 Thick + REST

C/S vs P2P — 音視訊通話才考慮 P2P

CAP Theorem → CAP 定理

決策：「暫時不一致會造成嚴重後果嗎？」→ 是 → CP；否 → AP（預設）

Scalability → 可擴展性

順序：先垂直，碰到上限或需高可用時再水平

水平擴展挑戰：Session 狀態、資料一致性（→ CAP）、LB SPOF

REST 要點 → REST 架構風格

狀態碼：401（未認證）vs 403（無權限）；201 Created（建立成功，搭 Location header）
參數：Path（指向資源）/ Query（篩選）/ Body（POST/PUT/PATCH 結構化資料）
反模式：POST /updateUser、GET /deleteUser、GET 帶 body

GraphQL 要點 → GraphQL 查詢語言

核心問題：

• N+1：batch resolver 用 DataLoader 合成 IN (...)
• Cache 難：POST + 單一 endpoint → 用 persisted queries 取回 CDN cache
• 惡意查詢：用 query complexity / depth limit

gRPC 要點 → RPC 與 gRPC

• Protobuf 二進位序列化 → ~10x JSON 吞吐量
• IDL（.proto） 定義介面，生成跨語言 stub
• HTTP/2 → 四種模式：unary / server stream / client stream / bidirectional
• 相容規則：新欄位用新 tag、刪除欄位 reserved、不改型別
• 陷阱：面試不要過早跳 gRPC；瀏覽器需 gRPC-Web

API Security → API 安全

AuthN vs AuthZ：「你是誰」vs「你能做什麼」

• JWT 放 Authorization: Bearer <token>
• Access token 短期 + Refresh token
• 不要把敏感資料放 JWT payload（只有 base64，非加密）

Consistent Hashing → 一致性雜湊

核心問題：hash(key) % N 在 N 變動時會搬走幾乎所有 key。

解法：

• Hash Ring：節點與 key 映射到圓環，順時針找第一個節點
• Virtual Nodes：每節點多個位置 → 分佈均勻 + 可按硬體能力分配

搬遷量：hash % N → O(K)；Consistent Hashing → O(K/N)。

觸發場景：Distributed Cache sharding、Cassandra/DynamoDB routing、Sticky Sessions、Rate Limiting、CDN edge routing。

索引結構決策 → 資料庫索引概論

B-Tree 要點 → B-Tree 索引

• 平衡多叉樹，葉節點距離相等
• B+Tree：只葉節點存資料 + 葉節點間 linked list → 範圍查詢更快
• InnoDB / PostgreSQL / MongoDB 都用 B+Tree 或近似變體

LSM Tree 要點 → LSM Tree

寫入：WAL → MemTable（SkipList）→ SSTable flush → Compaction

• 把隨機寫變順序寫 → 寫入吞吐極高
• 查詢用 Bloom Filter 跳過 SSTable
• 代價：寫放大 + 讀取可能多層

Hash Index 要點 → 雜湊索引

• hash(key) → bucket → O(1) 等值查詢
• 碰撞處理：Chaining or Open Addressing
• 不支援範圍、排序、前綴

Geospatial 要點 → 地理空間索引

Inverted Index 要點 → 倒排索引

• Term Dictionary + Posting List
• Posting 含 Doc ID、TF、positions（phrase query 用）
• 應用：Elasticsearch、Lucene、PostgreSQL FTS、MySQL FULLTEXT

Database Transactions → 資料庫交易

ACID：Atomicity / Consistency / Isolation / Durability

四種隔離等級

並發異常與解法

• Dirty Read：讀到未 commit 資料
• Non-repeatable Read：同 row 值變了
• Phantom Read：範圍查詢 row 數變了
• Lost Update（重要！）：兩交易同時改 → 後寫覆蓋前寫
  • 解：Optimistic Locking（version 欄位）或 Pessimistic Locking（SELECT FOR UPDATE）
• 超賣本質是 Lost Update：原子 UPDATE qty = qty - 1 WHERE qty > 0 即可，不要動隔離等級

分散式交易

• 2PC：強一致但脆弱（coordinator 崩潰會卡死）
• Saga：本地交易 + 補償，現代微服務主流

Sharding → 資料分片

Shard Key 三條件

1. 高基數（cardinality）
2. 均勻分佈
3. 契合查詢模式

三種策略

三大挑戰

Replication → 資料複寫

三大架構

Replication Lag 三大不一致

Failover 三大坑

• 非同步資料遺失 → 半同步 + 選資料最新的 follower
• Split Brain → STONITH / Fencing Token / Raft consensus
• Timeout 拿捏（太長復原慢、太短誤觸發）

Quorum（Leaderless）

公式：w + r > n → 讀寫節點必有重疊。
常見 n=3, w=2, r=2（容忍 1 個失效）。

Sloppy Quorum + Hinted Handoff：寫到「非家節點」暫存，網路恢復後送回家 → AP 配置。

Caching → 快取機制

快取位置（latency 由低到高）

In-Process（ns） < Redis 同區（< 1ms） < CDN（20–40ms）

四種模式

淘汰策略

LRU 預設（90% 工作負載適合）+ TTL 防過時。LFU 適合長期熱門，FIFO 幾乎不用。

三大陷阱

面試五步驟

1. 確認瓶頸 → 2. 決定快取什麼 → 3. 選架構（預設 Cache-Aside）→ 4. 淘汰策略（LRU+TTL）→ 5. 說缺點（失效 / 故障 / Stampede）

Numbers to Know → 系統設計關鍵數字

核心量級

Latency 量級直覺

memory ≪ disk ≪ network

• Memory（in-process）：ns
• Memory（Redis 同區）：< 1ms
• Disk（DB cached）：1–5ms
• Disk（DB uncached）：5–30ms
• Network（跨區）：10–100ms+

Scaling Reads → 讀取擴展

演進順序：index → denormalize / materialized view → read replica → cache（app + CDN）

Cache invalidation：TTL / write-through / write-behind / tagged / versioned keys

Scaling Writes → 寫入擴展

四策略：垂直選型 → sharding/partitioning → queue + load shedding → batching + 階層聚合

• DB 選型：Cassandra（append-only，10k+ 寫/秒）vs MySQL（B-tree update，~1k）
• Partition key：高基數均勻（hash(userID)）；爛 key（國家）→ shard 不均
• Horizontal sharding（分 row）vs Vertical partitioning（分 column）
• 爆發：Queue 吸收（短暫才用，會掩蓋問題）/ Load Shedding（丟最不重要的）
• Hot key 壓垮 shard：拆 sub-key（只適用可聚合 metrics）
• Resharding 不停機：dual-write 雙寫 + 讀新 shard

Long-Running Tasks → 長時間執行任務

核心：web server 回 job ID（ms） + worker pool 處理。queue 只放 job ID。

Queue 選型：Kafka（安全預設）/ SQS / RabbitMQ / Redis+Bull

Handling Large Blobs → 大型檔案處理

10MB → Blob Storage（S3）。Presigned URL 直傳 + CDN download，server 不碰 bytes。

• 限制烘焙進簽名：content-length-range、content-type
• 斷點續傳：Multipart Upload（S3 5MB+/塊）+ ListParts 續傳
• 狀態同步：Storage 事件（主）+ 對帳（安全網），別信任 client 通知
• 下載：CDN + Range Request（大檔案斷點續傳）
• 防濫用：quarantine bucket 掃描通過才可存取

Real-time Updates → 即時更新

兩個 hop：① client-server 協定　② server 端傳播

第一 hop（協定）：

第二 hop（傳播）：Pull（DB）/ Consistent Hashing（大量關聯狀態）/ Pub/Sub（廣播首選）

重連：heartbeat 偵測殭屍連線 + 序列號補發遺漏（Redis Stream）

Search System → 搜尋系統

不用 LIKE。獨立搜尋索引 + CDC + Kafka 非同步同步。

• 倒排索引（詞 → 文件）+ 文字分析（斷詞 / lowercase / stop word / stemming）
• Indexing pipeline：CDC（推薦） > 雙寫（非原子、易不一致）
• 排序：BM25（TF 有上限 / IDF 越罕見越高）+ Boosting（name^3）+ 業務指標
• Autocomplete：Edge N-gram + Redis（100ms 內）
• Faceted Search：Aggregation API（一次回結果 + 計數）
• Shard 數建立後不可改（10~50GB/shard）；零停機 Reindex 用 alias

RAG → 檢索增強生成 RAG

解 foundation model 限制：cutoff / 缺領域深度 / 缺私有資料 / 無法引用（hallucination 是症狀）

四元件：Ingestion → Retrieval → Augmentation → Generation

• Ingestion：chunking → embedding → vector DB（offline）
• Retrieval：Hybrid Search（dense semantic + sparse lexical）+ reranking
• Augmentation：query + context 組 prompt，「不知道就說不知道」降 hallucination
• vs fine-tune / 長 context：RAG 划算、可引用來源、知識即時、獨立調整
• Agentic RAG：agent 當 orchestrator（構建 query、驗證 context）

Data Pipeline → 資料管線設計

核心決策：批次 vs 串流（由延遲容忍度決定，< 10 分必串流）

• 架構：Kappa（單套串流，主流）vs Lambda（批+串雙管線，超大歷史分析）
• 轉換：ELT（倉儲內轉換，現代首選）vs ETL
• 三模式：CDC / Fan-out / Enrichment
• 容錯：at-least-once + 冪等寫入；Watermark 處理遲到事件（event time）
• 倉儲：Data Warehouse（schema-on-write）/ Data Lake（schema-on-read）/ Lakehouse

資料庫總覽與選型 → 資料庫總覽與選型

兩個正交維度看全景：資料模型（table / document / KV / wide-column / graph）× 工作負載（OLTP / OLAP）。

選型三問：① 資料形狀/查詢模式 → ② OLTP or OLAP → ③ 規模與一致性取捨。別一開始就背「SQL vs NoSQL」。
MVP / 純快取 / 純檔案 → 不要過度工程（SQLite、Redis、Blob Storage 各司其職）。

PostgreSQL → PostgreSQL

• 索引：B-tree（預設、等值/範圍/排序）；GIN（全文 tsvector、JSONB）；PostGIS/GiST（地理）；涵蓋索引 INCLUDE（免回表）；部分索引 WHERE（只索引子集）
• 豐富功能常省掉額外系統：GIN 全文搜尋 ≈ 取代 Elasticsearch（簡單需求）；JSONB ≈ 取代 MongoDB；PostGIS ≈ 地理空間 DB
• 寫入路徑：buffer + WAL（記憶體）→ commit 時 WAL fsync 落盤 → 背景寫髒頁 → 索引更新。單核 ~5k INSERT/s、~1–2k UPDATE/s
• 寫入擴展：垂直 → 批次 → write offloading（Kafka）→ 表分區 → sharding（無內建，需 Citus）
• 並發競態（拍賣出價）：Read Committed 下兩交易讀同一 maxBid → SELECT … FOR UPDATE（列鎖） 或 Serializable（需重試）
• 複製：同步（強一致、慢）/ 非同步（快、有 lag）；讀取擴展 read replica；read-your-writes → 剛寫的讀 primary；failover 提升 replica

何時偏離 PG：極端寫入（→ Cassandra）/ 全球多寫 active-active（→ CockroachDB/DynamoDB）/ 純 KV（→ Redis）。

DynamoDB → DynamoDB

• 全託管 NoSQL KV、schema-less、個位數 ms（DAX → 微秒）
• 主鍵：Partition Key（hash → 決定分區）+ Sort Key（分區內 B-tree 範圍/排序）；底層 = 中心化 hash 分區 + 分區內 B-tree
• 每請求選一致性：最終（預設、0.5 RCU）/ 強（ConsistentRead=true、1 RCU、不支援 GSI）
• 交易：TransactWriteItems，跨表最多 100 item，可序列化隔離
• 容量：1 RCU=4KB 強讀（或 2 次最終讀）；1 WCU=1KB 寫；每分區上限 ~3000 RCU / 1000 WCU
• DAX（讀寫快取，直連 DynamoDB 的寫才自動失效）、Streams（CDC → ES/Lambda/分析）、Global Tables（跨區）

OLTP vs OLAP → OLTP vs OLAP

column 對分析快三因素：① 只讀需要欄位（I/O 省 90%+）② 同型別高壓縮（字典編碼）③ 向量化 SIMD。
連接管線：ETL（先起步、簡單可靠有延遲）/ CDC（Debezium+Kafka，近即時、複雜）/ ELT+dbt（雲倉現代主流）。HTAP（TiDB/SingleStore）省管線但兩邊妥協。

Elasticsearch → Elasticsearch

• 概念：document / index / mapping / field；keyword（不分詞、像 hash）vs text（分詞、走 inverted index）；nested 正規化取捨；_version 樂觀鎖
• 底層：Lucene 之上的分散式協調層；Node 五型（master / data / coordinating / ingest / ML）；routing = hash(_id) % shards；shard × replica → 吞吐 X×Y
• Lucene segment 不可變：更新 = soft delete + 插新 doc，merge 才清 → 不適合高頻更新
• segment 內：inverted index（哪些 doc 符合）+ doc values（欄式，排序/聚合用）；query planner 用統計選 term 交集順序
• 分頁：from/size（深分頁貴）→ search_after → PIT cursor（一致視角）
• 限制：別當唯一 DB / source of truth、讀多寫少、最終一致、反正規化、CDC 同步權威來源

向量資料庫 → 向量資料庫

• embedding：128–1536 維陣列表示語意；相似度 Cosine（多 normalize、常見）/ L2 / Dot / Hamming(binary)
• KNN O(n) 太貴 → ANN：在 recall / latency / memory 三角平滑取捨

• filter：pre-filter（可能套不進索引）vs post-filter（可能不足 K）；hybrid（BM25 + vector）
• 選型階梯：先 pgvector / ES kNN / Redis VSS → 規模 >100M 才上 Pinecone / Weaviate / Milvus / Qdrant
• Numbers：1536 維 float32 ≈ 6KB/向量；HNSW 索引再 ×2；查詢 <10ms；recall 95%+
• 陷阱：非交易型（別當 source of truth）、embedding drift（換模型要重建）、cold start、索引建構慢

物件儲存（Blob Storage） → 物件儲存

• 耐久性 11 個 9（跨 ≥3 AZ 冗餘）≠ 可用性 99.99%（當下能否存取）
• 分層 Standard → IA → Glacier（越便宜取回越貴）+ 生命週期策略 自動降級
• 安全：私有 Bucket + Presigned URL + Block Public Access + 最小權限 IAM；版本控制（防誤刪/回滾）；CRR（非同步、DR/合規/讀延遲）
• 角色：DB 存 metadata + Blob 存內容；資料管線中繼（S3 event → Lambda）；靜態資源 + CDN；Data Lake（Parquet + Athena）

API Gateway → API 閘道

• 微服務統一入口，集中橫切關注點：路由 / 認證(JWT) / 限流 / SSL 終止 / 請求-回應轉換 / 請求聚合 / 快取

• SPOF → 多實例 + 前掛 LB；限流計數器 → 共享 Redis
• authN 在 Gateway（驗 JWT 簽名）/ 細粒度 authZ 在服務
• BFF：為 Web / Mobile / 第三方各維護一個 Gateway。別把業務邏輯塞爆 Gateway（→ 第二個 monolith）

負載平衡器（基礎設施） → 負載平衡器

• 功能：流量分配（最大化吞吐、避免局部過載）/ 健康檢查（含依賴）/ HA failover（VIP/anycast）/ SSL 終止 / Sticky Session（過渡，應外移 session）/ Global LB（DNS/Anycast）
• 演算法：Round Robin（預設）/ Least Connections（長連線）/ IP Hash（黏性）/ Weighted RR（混合規格）
• L4（WebSocket/長連線）vs L7（一般 HTTP，靈活路由）
• 面試：只在入口畫一個 LB 或省略只說「水平擴展」。網路層細節見 負載平衡

容器化與編排 → 容器化與編排

• Docker：Image（唯讀藍圖）/ Container（執行實例）/ 分層快取 / Registry
• K8s：Pod（最小單位）/ Deployment（維持 N 個 Pod）/ Service（穩定端點）/ HPA（自動擴展）；滾動更新零停機
• Stateless（狀態外移 Redis/DB/S3/ConfigMap）；liveness（活著嗎→重啟）vs readiness（能收流量嗎→移出 Service）probe

無伺服器運算（Serverless） → 無伺服器運算

• FaaS（Lambda，事件觸發、按毫秒計費）vs BaaS（Firebase/Auth0/S3）。面試講 Serverless 通常指 FaaS
• Cold Start（分配容器+初始化，幾百 ms~幾秒）vs Warm Start（保溫 5–15 分，無額外延遲）

• 適合：流量不穩 / 事件管線 / 排程 / 邊緣。不適合：>15 分長任務 / 低延遲 P99 / 持續高流量（貴）/ 複雜狀態
• 模式：API GW + Lambda；DB 連線爆炸 → RDS Proxy/PgBouncer 或 DynamoDB；SNS fan-out
• Cold Start 緩解：快語言 + 小包 + 初始化移 handler 外 + Provisioned Concurrency。vendor lock-in 明顯

分散式快取 → 分散式快取

難點不在「快」，而在 cache 自己變成一個要設計與維運的分散式系統（sharding / replication / failover / 一致性 / 流量偏斜）。

Cache replication 用 eventual consistency 即可 —— cache 不是 source of truth，丟資料代價低。
Consistent Hashing ≠ 解 hot key：分布均勻不等於流量均勻。
Invalidation 以 TTL 為主、廣播失效為輔：漏訊息最多 stale 一段 TTL，不會永久錯。

Redis → Redis

記憶體中的資料結構伺服器，單執行緒保證命令原子，速度優先換微秒延遲與多用途瑞士刀。

耐久性是取捨：RDB 兩快照間掉資料、AOF everysec 最多掉 1 秒；要真耐久用 AWS MemoryDB。
單執行緒陷阱：一條 O(N) 大命令（KEYS *）卡全場，用 SCAN 取代。
Pub/Sub 會丟、Streams 可重播：需可靠投遞別用純 Pub/Sub。

訊息佇列 → 訊息佇列

Queue 是緩衝層，買到非同步 / 解耦 / 削峰填谷；代價是最終一致、亂序、重複投遞，且它不增加系統容量，只是把過載往後推。

Queue 不是銀彈：解決時間不均與耦合，不解決整體吞吐不足。
多 consumer 必失序：靠 partition key 路由 + 單 consumer 保序，代價是該 key 吞吐受限。

Kafka → Kafka

分散式 append-only commit log，可同時當可水平擴展的 message queue 與可重播的 event stream。一句話：always available, sometimes consistent（AP）。

順序保證只在單一 partition 內，非整個 topic。
預設 at-least-once：commit 前掛會重複 → 下游冪等或 transactional API。
Anti-pattern：大檔塞 Kafka；應存 S3，topic 只放指標訊息。

分散式鎖 → 分散式鎖

讓多台機器對共享資源互斥。核心難點不是上鎖，而是「持鎖節點當機如何安全釋放」與「鎖過期但節點以為仍持鎖」。第一個該問：真的需要鎖嗎？

效率鎖 vs 正確性鎖：效率 → Redis SET NX EX 夠；正確性 → fencing token（單調遞增，資源拒收較舊 token）+ 共識儲存。
釋放不能裸 DEL：寫唯一 token，Lua 原子 check-and-delete，否則誤刪別人的鎖。
臨界區比 TTL 久：用「安全 TTL 上界 + fencing token」而非靠 watchdog 續租。
同一 DB 內競爭別上外部鎖：優先 FOR UPDATE 或樂觀鎖（version + CAS）。

ZooKeeper → ZooKeeper

強一致、高可用的分散式協調服務（非資料庫）：ZNode + ensemble + watches 組出服務發現、設定管理、leader 選舉、分散式鎖。讀多寫少、資料 < 1MB、CAP 選 CP。

ephemeral 是殺手鐧：session 結束自動刪 → 免費故障偵測，由 ensemble 統一裁決「誰死了」。
leader 選舉避免羊群效應：只 watch 序號小一號的節點。
follower 讀可能 stale：要最強一致先 sync。
Kafka 已從 ZooKeeper 遷 KRaft（內建共識取代外部協調）。

內容傳遞網路（CDN） → 內容傳遞網路

地理分散的快取網路，把內容複製到離使用者最近的 Edge，用空間換時間降延遲並把流量擋在源站外。本質是分散到全球的 read-through cache。

別用短 TTL 求即時：摧毀 hit ratio、打爆源站；正解是 immutable + hash busting。
Cache Hierarchy（Origin Shield）：收斂數百 Edge 的回源，把源站 QPS 從 Edge 數量級降到物件數量級。
CDN SPOF：Multi-CDN + DNS 故障切換 + fallback Origin（源站要能直接服務）。
動態內容也能加速（就近 TLS、骨幹路由、連線重用），但每人不同的回應不可快取，別在所有流量前都畫 CDN。

處理競爭 → 處理競爭

多個 process 搶同一資源造成 race condition。心法是複雜度遞進：能塞進單一 DB 就用 pessimistic/optimistic，不行才上分散式協調。

Atomicity 擋不住 race：transaction 只保證自身內部，擋不住別人同時讀到一樣的資料。
OCC 版本號用單調遞增欄位（如 review_count）避免 ABA。
黃金法則：盡量把有 contention 的資料放同一個 DB，避開整個分散式協調。
Hot partition / 名人問題：先質疑能否改變問題；真需強一致用 queue-based serialization（單 worker）。
別過度設計：簡單 row lock / OCC 就夠時別硬上 distributed lock。

過載保護 → 過載保護

核心是讓系統在壓力下優雅降級而非全面崩潰（10 倍流量下還能服務 30%）。層層疊加的多層防線，每層擋的東西不同。

Rate ≠ Concurrency limiting：前者管每秒幾個、後者管同時處理中的數量（更貼近資源）。
分散式限流：集中式 Redis 計數器（INCR+EXPIRE/Lua）；被限流回 429 + Retry-After。
擴容快、縮容慢防振盪；空窗靠預測擴容 + load shedding + 佇列緩衝。
Load Shedding（丟不丟）vs Prioritization（丟誰）vs Backpressure（放慢不丟）。

可靠交付 → 可靠交付

故障是常態。由細到粗、層層疊加的防線：超時 → 重試 → 冪等性 → 退避加抖動 → 故障切換 → 降級。目標不是防故障，而是讓故障時優雅應對、自動恢復、不放大災情。

at-least-once + 冪等 Consumer + 去重表 = 等效 exactly-once（不需真 exactly-once）。
該重試 vs 不該：5xx/網路重試；4xx/業務錯誤/非冪等不重試；上限 3~5 次。
熔斷器三狀態 Closed → Open → Half-Open（探針成功逐步放量）。
Failover（找健康同類）vs Fallback（用簡陋替代撐過去）。

可觀測性 → 可觀測性

從外部輸出推斷內部狀態。三支柱回答三個不同問題，互補不替代；並用 SLI/SLO/SLA + Error Budget 把可靠性量化。

排查口訣：Metrics 告警 → Traces 定位 → Logs 確診。

P99 必須用 Histogram，平均值會被快請求拉低掩蓋尾端。
對症狀告警（用戶有感）不對原因（CPU 高），避免告警疲勞。
高基數（user_id）放 Logs/Traces，別塞 Metrics label（時序爆炸）。
SLA < SLO 留緩衝；SLO 別設 100%（99.9% → 每月約 43 分鐘 error budget）。

案例招牌取捨速查（Case Studies）→ 案例研究

Related

• 學習地圖
• 面試陷阱題