校招准备的逻辑
回想一下校招季是怎么准备的：刷算法题、背操作系统知识点、记网络协议分层、把常见的设计模式过一遍。目标是"这些领域的东西我都会"。
这个策略在逻辑上是成立的。校招面对的是完全没有工作经验的人，面试官没法从项目经历里判断能力，只能从基础知识和潜力来看。基础知识扎实、算法能写出来，说明学习能力没问题，以后能培养。
校招的核心矛盾是：面试官和候选人之间信息极不对称。你没有工作经验，他没法从履历里判断你行不行，所以只能用基础知识作为代理指标。你能做的，就是把这些代理指标都刷到没有短板。
社招准备的逻辑完全不同
社招面对的不再是"有没有潜力"，而是"能不能直接上手"。你写的每一行代码都在生产环境里跑过，你的每一个项目经验都是真实的。面试官不需要猜，直接问细节就能判断。
这个变化让准备的逻辑完全变了。
校招是在已知范围里查漏补缺。 考核范围是相对固定的：计算机基础、算法、一门主语言。候选人要做的就是把这些范围内的东西都掌握到一定水平。
社招是在未知范围里展示深度。 没有固定范围，任何你做过的技术都可能问，任何你用过的工具都可能挖。但考核的核心不再是"会不会"，而是"理解有多深、能不能做判断"。
用刷校招的方式刷社招，会遇到一个很尴尬的问题：花了很多时间把"React 基础"过了一遍，面试问的全是"你们项目里 React 是怎么用的、遇到过什么坑、怎么解决的"。这不是靠背能回答的。
本质差异一：校招考范围，社招考深度
校招的问题通常是标准化的。链表反转、二叉树遍历、Dijkstra 算法，答案相对固定，会就是会，不会就是不会。
社招的问题通常是开放的。"说说 React 的更新流程"，可以简单答一句，也可以讲半小时，全看你能讲多深。面试官不是要找一个"把所有知识点都背住"的人，而是要找一个"真正理解 React 是怎么工作的"的人。
深度怎么体现？不是靠背答案背出来的，是靠在真实项目里踩过坑、排查过问题、设计过方案，一点一点积累出来的。面试官有办法判断：问你一个细节，如果你真的做过，会讲得很顺滑，会有具体的数值和案例；如果你只是背的，会讲得很模糊，经不起追问。
深度体现示例
# 没有深度的回答（背答案）
面试官：useEffect 的依赖数组怎么决定？
候选人：看这个 effect 依赖哪些外部变量，就把这些变量放进依赖数组里。
# 有深度的回答（理解机制）
面试官：useEffect 的依赖数组怎么决定？
候选人：
这要从 React 的调度机制说起。useEffect 的依赖数组是用来告诉 React："这个 effect 依赖哪些值，当这些值变化的时候，我需要重新执行这个 effect"。
React 通过比较依赖数组里每一项的引用来判断是否变化。这里有个关键点：React 的比较是浅比较，所以如果依赖数组里放的是一个对象，每次渲染这个对象引用都会变，effect 就会重新执行。
这就引出了常见的问题——为什么有时候会死循环？因为 effect 里改变了依赖数组里某个值，比如 setState，导致 effect 重新执行，又改变这个值，又触发 effect，形成循环。
所以实际项目中，我一般会遵循几个原则：
1. 依赖数组里只放必要的值
2. 如果 effect 里用到了某个值，但不想让它触发 effect，用 useRef
3. 优先使用 useCallback 或 useMemo 来稳定引用
本质差异二：校招靠记忆，社招靠理解
校招准备很多时候靠的是记忆。把常见题型刷三遍，形成肌肉记忆，考试的时候能写出来就行。
社招靠记忆的效果很差。面试官稍微追问一下"这个方案你们当时为什么选这个"、"那个版本遇到过什么问题"，背答案的人立刻露馅。
真正有效的社招准备是把技术理解到能"推出来"的程度。比如被问到 useEffect 的依赖数组，不是在脑子里搜索"依赖数组的规则是什么"，而是从 React 的调度机制出发，理解"依赖数组是用来决定 effect 什么时候该重新执行的，React 通过比较依赖是否变化来决定要不要重新运行这个 effect"，然后基于这个理解，自己能推出来"什么情况下会死循环"、"为什么有时候需要用 useRef 来保存不变的值"。
能推出来和能背出来，在面试里表现出来的状态完全不同。
理解 vs 记忆的表现对比
| 场景 | 记忆型 | 理解型 |
|---|---|---|
| 被问到熟悉的问题 | 能背出来，但语气机械 | 能用自己的话讲，语气自然 |
| 被追问细节 | 容易卡住或前后矛盾 | 能顺着逻辑继续推导 |
| 被问到边缘情况 | 不知道，没想过 | 能分析原因，给出推断 |
| 换个问法 | 识别不出是同一类问题 | 能识别出本质相同的问题 |
本质差异三：校招看单体，社招看联网
校招的问题通常是独立的。算法题、设计模式题、网络协议题，一道题考一个知识点，答好这道题就行。
社招的问题通常是联网的。问 React 更新流程，连接着 Fiber 架构、lane 模型、并发特性、hooks 的实现原理。问浏览器缓存，连接着 HTTP 协议、CDN 原理、Service Worker、离线存储。问性能优化，连接着浏览器的渲染流水线、重排重绘、CSS 动画、JavaScript 执行效率。
面试官希望看到的是：你脑子里有一张网，提到一个点，能迅速连接到其他相关点上。如果你只能孤立地讲一个知识点，面试官就会觉得你的理解还是零散的。
知识联网示例
# 孤立的知识
React 的 useEffect 依赖数组规则：
1. 必要依赖必须包含
2. 不要包含不必要依赖
3. 依赖数组变化会触发 effect 重新执行
# 联网的知识
useEffect 依赖数组 → React 更新机制 → Fiber 架构 → lane 模型
useEffect 依赖数组 → 闭包陷阱 → useCallback/useMemo → React.memo
useEffect 清理函数 → React 18 cleanup 行为变化 → Concurrent Mode
本质差异四：校招准备靠时间，社招准备靠方法
校招准备通常有时间保障。秋招春招节奏是固定的，有大块时间可以集中准备，刷题、背知识点都能按计划推进。
社招通常是在职准备。工作日要上班，下班要处理杂事，能用来准备的时间是碎片化的。靠时间堆积的方式效率很低。
在职准备需要的是方法：怎么在有限时间里最高效地补齐弱项、怎么把碎片时间利用起来做练习、怎么在工作中有意识地积累面试素材。
碎片时间的高效利用
碎片时间适合做什么？适合做"输出性练习"，而不是"输入性学习"。
# 低效：碎片时间看文章（输入）
场景：地铁上刷一集 React 源码解析视频
问题：看的时候觉得懂了，看完就忘，没有形成自己的理解
# 高效：碎片时间录音练习（输出）
场景：地铁上对着手机讲五分钟"useEffect 的依赖数组"
问题：强迫自己组织语言，讲完自己听一遍，发现哪里讲不通
在职准备的时间分配
# 日常工作中
- 20% 的时间：有意识地积累项目素材
- 遇到的问题、解决的方案、背后的权衡
- 写工作日志记录技术细节
# 通勤时间
- 30 分钟：录音练习（输出）
- 讲一个技术概念 / 讲一个项目亮点
- 自己回听，找出不清晰的地方
# 周末时间
- 2 小时：骨架建设（连接）
- 画一个领域的骨架图
- 找骨架上的弱点，专项学习
# 面试前一周
- 模拟面试练习
- 对着骨架过一遍
- 准备 STAR 格式的项目故事
社招准备的正确思路
总结一下，社招准备的正确思路是什么？
思路一：搞清楚考察维度
搞清楚自己被考察的维度：编程能力、技术深度、技术判断、表达清晰度。不需要平均用力，只需要对每个维度有基本的把控能力，然后在最强项上建立差异化优势。
面试不是要把所有候选人都变成同一个样子。面试官在找的是有亮点的人，你的亮点是什么？是深度、是广度、还是表达清晰？搞清楚自己的优势，在面试里放大它。
思路二：从"记住答案"切换到"理解机制"
能用自己的话把一个技术原理讲清楚，比能背诵十遍标准答案有用。
怎么检验自己是不是真的理解了？三个标准：
- 能讲：能不能对着一个不懂这个技术的人讲清楚
- 能推：给一个没见过的问题，能不能顺着机制推出来
- 能比：能不能把这个技术和同类技术放在一起比较
思路三：把碎片时间从"输入"切换到"输出"
看一篇文章是输入，讲出来是输出。输入是被动的，输出是主动的。只有输出才能检验自己是不是真的理解了。
每天花 15 分钟做输出练习，比花 2 小时看文章有用得多。
思路四：把项目经验串成故事
项目经历不是简历上的一句话，而是包含背景、挑战、方案、结果、反思的完整叙事。面试里问项目，不是想知道你做了什么，是想通过项目判断你的思维方式和技术判断力。
STAR 格式准备项目故事
# Situation（背景）
我们当时面临的问题是：电商网站首屏加载时间 8 秒，转化率只有 2.3%。
# Task（任务）
我作为前端负责人，需要解决这个问题。
# Action（行动）
我做了三件事：
1. 用 Lighthouse 分析定位问题：第三方 SDK 占了 70% 的 JS 体积
2. 实施拆包方案：把第三方 SDK 按需加载，保留核心支付和统计
3. 实现完整的缓存策略：强缓存 + Service Worker
# Result（结果）
首屏加载时间从 8s 降到 1.8s，转化率从 2.3% 提升到 4.1%。
社招准备的常见误区
误区一：用校招的方式刷社招
把"前端基础知识"当成一个固定的考试范围来准备，花大量时间背概念、背标准答案。但面试问的全是项目细节和深度追问，背的答案完全用不上。
误区二：追求技术栈的广度
觉得自己技术栈不够全面，花时间学这个框架、那个工具。但社招不是找全栈工程师，是在某个领域有深度的人。广度不等于优势。
误区三：只准备技术，不准备表达
花大量时间研究技术原理，但不练习怎么讲出来。面试的时候脑子里知道，但表达混乱，面试官看不出你的深度。
误区四：把项目经历当成功能清单
项目介绍讲成流水账：这个模块用了什么技术、那个功能怎么实现的。但面试官想听的是你的判断力、你的决策能力、你解决问题的思路。
这一章想说的
校招和社招是两种完全不同的游戏规则。用校招的方式准备社招，既浪费时间，又打不到点子上。
社招看的是深度、理解、判断和表达，不看记住了多少知识点。对着这四个维度去准备，比漫无目的地刷材料有效得多。
社招准备的核心是：
- 建骨架：把知识点连成网
- 练表达：把理解变成可输出的内容
- 串故事：把项目经验变成完整的叙事
- 找优势：搞清楚自己的亮点并放大它
接下来的章节会具体讲怎么建知识骨架、怎么训练表达、怎么把项目经验变成面试叙事。