🔄 复习日 Day 5 / Review Day 5
📊 Day 5/150 · NeetCode: 4/150 · SysDesign: 4/40 · Behavioral: 4/40 · Frontend: 4/50 · AI: 2/30
🔥 3-day streak!
今天是复习日！回顾过去4天的内容。
Today is a review day! Let's revisit the past 4 days.
📝 Quick Quiz — 3 Mini-Reviews
从系统设计、算法、前端三个板块各出一题——先别看答案，想想你记得多少！
One question each from System Design, Algorithms, and Frontend — try to answer before peeking!
Q1: [🏗️ System Design] From Day 4 — Load Balancing
你有一个 Load Balancer 后面跟着 3 台服务器。用户登录后，Session 存在 Server 1 的内存里。下一个请求被路由到 Server 2——用户发现自己被登出了。
You have a load balancer in front of 3 servers. User logs in, session stored in Server 1's memory. Next request routes to Server 2 — user is logged out.
问 / Question: 这个问题叫什么？列出两种解决方案，并说明各自的取舍。
What is this problem called? Name two solutions and explain the tradeoff of each.
<details>
<summary>显示答案 / Show Answer</summary>
这叫 Session Affinity（会话粘性）问题，或 Sticky Session 问题。
服务器无状态（Stateless）是 REST 的核心原则，但当状态存在单台服务器内存时，负载均衡就破坏了这个假设。
解决方案 1：Sticky Sessions（粘性会话）
Load Balancer 记住"用户 A → 永远去 Server 1"。
- ✅ 简单，无需改动应用层
- ❌ 如果 Server 1 宕机，所有绑定它的用户 session 丢失；负载不均衡
解决方案 2：Shared Session Store（共享 Session 存储）
Session 不存在各服务器内存，而是存在 Redis 等共享缓存里。所有服务器读写同一个 Redis。
- ✅ 任何服务器都能处理任何请求，真正无状态
- ❌ 引入 Redis 作为额外依赖；Redis 本身需要高可用设计
关键洞察（From Day 4）： 负载均衡解决了"一台服务器扛不住"的问题，但同时暴露了"状态共享"的问题。真正可扩展的系统需要无状态的应用层 + 独立的状态层（数据库/缓存）。
</details>
Q2: [💻 Algorithms] From Days 2–4 — Arrays & Hashing Pattern
下面这段代码是什么算法的思路？时间复杂度是多少？它和 Day 2 的 Valid Anagram 有什么共同的核心思想？
What algorithm pattern does this code skeleton represent? What's the time complexity? How does it share a core idea with Day 2's Valid Anagram?
def mystery(nums):
seen = {}
for i, num in enumerate(nums):
complement = target - num
if complement in seen:
return [seen[complement], i]
seen[num] = i<details>
<summary>显示答案 / Show Answer</summary>
这是 Day 3 的 Two Sum 解法。
时间复杂度：O(n) — 只遍历一次数组，dict 的查找是 O(1)。
空间复杂度：O(n) — 最坏情况存储 n 个元素。
和 Valid Anagram 的共同核心思想：
Two Sum 和 Valid Anagram 都是 Arrays & Hashing 模式的经典题。核心思想是：
"用哈希表把 O(n²) 的"两层循环查找"压缩成 O(n) 的"一次遍历 + 字典查询"。"
Use a hash map to trade O(n²) nested search for O(n) single-pass lookup.
- Valid Anagram：用哈希表统计字符频率，把"逐个比对"变成"对比频率表"
- Two Sum：用哈希表记录"已见过的数"，把"两层循环找配对"变成"一次扫描找补集"
这个思路是 NeetCode 150 中出现频率最高的模式之一——遇到"在数组里找某种关系"的题，先想哈希表！
</details>
Q3: [🎨 Frontend] From Day 4 — Responsive Design & Media Queries
不看代码，回答：@media (min-width: 768px) 这条规则，在什么情况下生效，在什么情况下不生效？
Without looking at code: when does @media (min-width: 768px) apply, and when does it not?
然后：如果同时有 min-width: 768px 和 min-width: 1200px 两条媒体查询，都在 1400px 宽度下，会发生什么？
Then: if you have both min-width: 768px and min-width: 1200px rules, what happens at 1400px width?
<details>
<summary>显示答案 / Show Answer</summary>
@media (min-width: 768px) 生效条件：
- 视口宽度 ≥ 768px → 规则生效（应用样式）
- 视口宽度 < 768px → 规则不生效（忽略样式）
- 这是"Mobile-First"写法的基础——默认样式给手机，
min-width逐步增强给更大屏幕。
两条规则同时存在时（1400px 宽度）：
1400px ≥ 768px → 第一条生效 ✅
1400px ≥ 1200px → 第二条也生效 ✅
两条都生效！CSS 的层叠规则决定最终样式：
- 两条规则中相同的属性，后写的（声明顺序靠后的）优先
- 所以应该总是把
min-width从小到大排列写：先 768px，再 1200px - 这样大屏幕的样式会自然覆盖中等屏幕的样式
关键记忆（From Day 4）： Media queries don't "turn off" — they cascade. The last rule wins. Order matters!
</details>
💡 复习巩固记忆，螺旋式上升。
Review reinforces memory — spiral upward.
📅 明天继续新内容！/ New content resumes tomorrow!