🔄 复习日 / Review Day — Day 35 (2026-05-05)

今天是复习日！回顾过去4天的内容。(Days 31–34)

📊 本轮覆盖主题 / Topics Covered:

• Day 31: Video Streaming (YouTube/Netflix), Largest Rectangle in Histogram, 衡量项目成功, Prototypes & this, AI News
• Day 32: Google Maps, Binary Search, 为不受欢迎的技术决策辩护, Debounce & Throttle, Function Calling & Tool Use in LLMs
• Day 33: Uber/Lyft Ride Sharing, Search a 2D Matrix, 与难相处的同事合作, Deep Clone/Flatten/Curry, AI News
• Day 34: File Storage (Google Drive/Dropbox), Koko Eating Bananas, 保持技术技能更新, React Performance re-renders, Context Windows

📝 Quick Quiz — 3 Mini-Reviews

Q1: [🏗️ System Design — Video Streaming / File Storage]

在设计 YouTube 这样的视频流服务时，为什么视频文件不直接存储在关系型数据库中？上传流程的关键步骤是什么？

When designing a video streaming service like YouTube, why are video files not stored directly in a relational database? What are the key steps in the upload pipeline?

<details><summary>显示答案 / Show Answer</summary>

核心答案：

视频文件是非结构化的二进制大对象（blob），体积庞大（可达 GB 级别），关系型数据库不适合存储和流式传输这类数据。正确做法是将视频存储在对象存储（如 S3、GCS）中，数据库只保存元数据（标题、URL、时长、状态等）。

上传流程关键步骤：

1. 客户端上传原始视频到对象存储（通过预签名 URL，绕过应用服务器）
2. 触发异步任务队列（如 SQS/Kafka）
3. 转码服务将视频编码成多种分辨率（360p / 720p / 1080p / 4K）
4. 切片成 HLS/DASH 分段（通常每段 2–10 秒）
5. 分发到 CDN，更新数据库状态为 "ready"

</details>

Q2: [💻 Algorithms — Binary Search Variants]

Binary Search 和 Koko Eating Bananas 都用了二分搜索，但思路不同。解释"在答案空间上二分"（Binary Search on the Answer）这个模式，它与标准二分有什么区别？

Both Binary Search and Koko Eating Bananas use binary search, but with different mindsets. Explain the "binary search on the answer space" pattern — how does it differ from standard binary search?

<details><summary>显示答案 / Show Answer</summary>

核心答案：

标准二分搜索：在已排序的数组中找一个具体的值（目标元素）。搜索空间是数组的下标。

在答案空间上二分（Koko、Search 2D Matrix 变种）：你不是在找数组里的元素，而是在找满足某个条件的最小/最大值。关键是找到一个单调性：某个阈值以下的答案都太小，以上都可行（或反之）。

Koko 的思路：

lo, hi = 1, max(piles)
while lo < hi:
    mid = (lo + hi) // 2
    if can_finish(piles, mid, h):
        hi = mid       # mid 可行，试试更小
    else:
        lo = mid + 1   # mid 不够，必须更大

识别信号：题目问"最小的 X 使得……"或"最大的 X 使得……"→ 基本就是在答案空间二分。

Key insight: Standard binary search finds a target in a sorted array (search space = indices). "Binary search on the answer" finds the minimum/maximum value satisfying a condition (search space = possible answers). The prerequisite is monotonicity: once a value works, all larger values also work (or vice versa). Signal phrases: "minimum speed such that...", "minimum capacity such that...", "maximize the minimum...".

</details>

Q3: [🎨 Frontend — React Performance & JS Fundamentals]

你在做代码审查，看到这段代码：

function ParentComponent() {
  const [count, setCount] = useState(0);
  
  const handleClick = () => console.log('clicked');
  
  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
      <ExpensiveChild onAction={handleClick} />
    </div>
  );
}

每次点击 +1，ExpensiveChild 都会重新渲染。为什么？如何修复？

Every time +1 is clicked, ExpensiveChild re-renders. Why? How do you fix it?

<details><summary>显示答案 / Show Answer</summary>

核心答案：

为什么会重渲染？

每次 ParentComponent 渲染时，handleClick 都是一个全新的函数引用。即使逻辑完全相同，() => console.log('clicked') 每次都创建新的函数对象。ExpensiveChild 收到的 onAction prop 引用变了，即使用了 React.memo 也会触发重渲染。

如何修复：

// ✅ 用 useCallback 稳定函数引用
const handleClick = useCallback(() => {
  console.log('clicked');
}, []); // 空依赖数组 = 只创建一次

// 同时用 React.memo 包裹子组件
const ExpensiveChild = React.memo(({ onAction }) => {
  // ...
});

双保险：useCallback 保持函数引用稳定 + React.memo 跳过相同 props 的重渲染。只用其中一个没有效果——memo 需要稳定的引用，useCallback 没有 memo 也不会阻止子组件渲染。

</details>

💡 复习巩固记忆，螺旋式上升。Review strengthens memory — knowledge compounds over time.

📅 明天继续新内容！Tomorrow, back to new material!

Day 35 · Review · Mastery Phase · byte-by-byte