先选一条路线
1
V2
Vue 2
16 节 · 24 段示例 · 10 张解析图
先看清它的限制
。故意写成"哪里会出问题":四个监听盲区、数组七个方法、双端比较什么时候多挪 DOM。
必看 02040810
打开 →
2
V3
Vue 3
16 节 · 24 段示例 · 9 张解析图
每一项改动,都是在还债
。Proxy 补四个洞、PatchFlag 把"比什么"编译进去、LIS 少挪 DOM。
必看 01040810
打开 →
3
Re
React
21 节 · 31 段示例 · 10 张解析图
别背结论,把它推一遍
。state 是快照、批处理、闭包陷阱、Fiber 为什么能打断自己。
必看 03040708
打开 →
4
Rt
前端路由
12 节 · 9 段示例 · 10 张解析图
刷新 404 的时候,前端根本不知道
。hash 与 history 差在哪、守卫的完整顺序、权限做过滤还是动态注册。
必看 01020609
打开 →
5
St
状态管理
11 节 · 7 段示例 · 9 张解析图
状态放在哪,比用什么库更重要
。Pinia 凭什么砍掉 mutations、Redux 为什么要求纯函数、订阅粒度决定谁重渲染。
必看 01030408
打开 →
6
MP
小程序
14 节 · 9 段示例 · 10 张解析图
不是小号的网页
。双线程与 setData 的成本、分包、登录为什么换不到 openid、uni-app 与 Taro 的编译路线。
必看 01030708
打开 →
1
Jv
Java 核心
19 节 · 18 段示例 · 10 张解析图
题都出在语义边界上
。== 和 equals 差在哪、循环拼接为什么是平方级、HashMap 何时树化、for-each 里删元素为什么会静默跳过数据。
必看 01030607
打开 →
2
Sp
Spring / Boot
16 节 · 15 段示例 · 10 张解析图
所有问题都指向一件事
。调用有没有经过代理:事务失效、AOP 失效、循环依赖、Bean 生命周期,全是这一条的推论。
必看 03050610
打开 →
3
My
MySQL
18 节 · 17 段示例 · 10 张解析图
慢的 SQL 都慢在同一个地方
。索引没走对,或者锁等太久。key_len、rows、Extra 三列就能定位九成慢查询,剩下一成藏在 MVCC 和间隙锁里。
必看 02051112
打开 →
4
Cn
Java 并发
16 节 · 15 段示例 · 10 张解析图
并发的事故都是「以为锁住了」
。锁错了对象、volatile 当原子用、队列无界把堆撑爆、ThreadLocal 忘 remove 导致串号。每节都给一段会真出问题的代码。
必看 02030409
打开 →
5
VM
JVM
14 节 · 12 段示例 · 10 张解析图
最后都落到日志里那句话
。OOM 冒号后面那句、jstack 里那个十六进制线程号——两条线索解决八成线上问题。空对象 16 字节、栈深两万多,都是真跑出来的。
必看 05070811
打开 →
6
Rd
Redis
14 节 · 13 段示例 · 10 张解析图
缓存的问题从来不在缓存本身
。它挂了怎么办、和库对不上怎么办、一个慢命令把整个实例卡死怎么办。穿透击穿雪崩是三种病,解法完全不同。
必看 02050809
打开 →
1
Bd
打包工程化
15 节 · 7 段示例 · 10 张解析图
打包器其实只做三件事
。loader 与 plugin 的分界、Vite 为什么快、contenthash 与长缓存。
必看 03050709
打开 →
2
Np
npm 包设计
14 节 · 8 段示例 · 10 张解析图
别人凭什么敢用你的包
。exports 为什么 types 要写最前、peerDependencies 解决什么、双包陷阱。
必看 01020305
打开 →
3
Pf
性能优化
14 节 · 8 段示例 · 10 张解析图
先量,再改
。LCP / INP / CLS、长任务与时间切片、布局抖动,每条手段都先讲机制。
必看 01060708
打开 →
4
Te
前端测试
10 节 · 5 段示例 · 9 张解析图
覆盖率 100% 的代码照样全是 bug
。金字塔为什么这么分、什么时候该 mock、覆盖率怎么读才不被骗。
必看 01040507
打开 →
5
Gt
Git 工作流
11 节 · 9 段命令推演 · 9 张解析图
reset 和 revert 差的是别人的仓库
。三个区域怎么流转、merge 与 rebase 怎么选、reflog 怎么救回误删的提交。
必看 02030709
打开 →
6
Db
排查定位
13 节 · 5 段示例 · 10 张解析图
会排查的人先缩范围
。白屏、变慢、内存涨、CPU 高,每种症状一条最短的定位路径,以及先止血还是先定位。
必看 01020609
打开 →
1
Ar
架构设计
19 节 · 11 段示例 · 10 张解析图
0 到 1 的难点是判断
。不可逆决策怎么排、目录按什么分、请求层怎么封、Node 怎么分层、什么时候该拆。
必看 01081016
打开 →
2
它解决的不是技术问题,是组织问题
。沙箱三种实现、样式隔离四代、谁管 URL、什么情况下不该上。
必看 02030809
打开 →
3
Sc
场景设计题
11 节 · 7 段示例 · 9 张解析图
先问清约束,再谈方案
。大文件分片怎么失败重传、断点续传与秒传、扫码登录的两种实现。
必看 02030406
打开 →
4
Al
手写算法
15 节 · 12 张解析图 · 12 个演示
写出答案只是及格线
。双指针、滑窗、链表、DP、回溯与 TopK,每类题该说什么、该写什么,都配一张解析图和能一步步点的演示。
必看 01071014
打开 →
5
Hc
手写代码题
15 节 · 14 张解析图 · 13 个演示
考的是细节不是记忆
。防抖、深拷贝的循环引用、Promise 三要素、bind 的 new 语义、并发池,每道都配一张解析图和能一步步点的演示。
必看 01030514
打开 →
五根暗线
三十二份材料看着是二十九个话题,其实有几根线把它们串在一起。面试里真正拉开差距的,
往往不是某个 API 的细节,而是你能不能在这些线上讲出"为什么不同"。
01一次数据变化,怎么走到 DOM
谁负责发现变化 → 谁负责算最小改动
Vue 2
defineProperty 在属性被赋值的那一刻就知道变了,Dep 精确通知对应的 Watcher,再走双端比较。发现得最早,但只对已有 key 有效。
Vue 3
Proxy 代理整个对象,新增和删除一样能拦到;再靠编译期的 PatchFlag 告诉运行时"这个节点只有 text 会变",比较范围被提前缩小。
React
不做拦截。state 变了就整个函数重新执行,拿到一棵新的 element 树,再靠 diff 反推要改哪里。发现得最晚,但换来了"state 是不可变快照"这个简单模型。
状态管理 05
同一个 store,订阅粒度决定了谁会重渲染:Zustand 用 selector 挑字段,Pinia 的 setup store 拆成多个独立 ref,Redux 得靠 useSelector 自己比。库和库的差别有一半在这里。
所以 React 的性能问题几乎都能归结为"不该重渲染的组件重渲染了",而 Vue 的性能问题几乎都归结为"该发现的变更没被发现"。两边的优化手段长得完全不一样,根子在这里。
02一段代码,从仓库到用户屏幕上
git 决定发哪份 → npm 决定分发 → 打包决定产物 → 浏览器决定加载 → 性能决定体验
Git 02
它决定发出去的是哪一份历史。merge 保留分叉,rebase 重写成一条直线,代价是 commit hash 全变——所以只能重写自己还没推出去的部分。
npm
exports 决定用户能拿到哪份产物、sideEffects 决定它能不能被摇掉。包的设计直接决定了别人打包时有多少优化空间。
打包
tree-shaking 删掉没用的代码,代码分割把非首屏的推后,contenthash 让缓存能长期有效。
浏览器
强缓存命中就根本不发请求,协商缓存换来一次 304。资源提示决定谁先下。
性能
最后落到 LCP、INP、CLS 三个数字上。前三步的每个决定,最终都在这三个数字上体现。
被问"怎么优化首屏"时,从这条链上找一个环节回答,比无序列一堆手段有说服力得多:是包太大、还是没拆、还是缓存策略错了、还是关键资源被阻塞了。
03HTML 到底在哪一步生成
CSR / SSR / SSG / ISR,以及渲染完谁来接管
Node 15
四种模式的分界线只有一条:HTML 是在请求时生成、构建时生成,还是根本不在服务端生成。首屏时间和可交互时间不是一回事。
Node 16–17
renderToString 出一段字符串,客户端 hydrateRoot 接管。手写一遍才知道坑在哪:数据必须序列化塞回页面,而且 < 不转义就是一个 SSR 独有的 XSS 口子。
Nest 15
两条完全不同的路:@Render 加模板引擎(服务端拼 HTML,没有 hydration),或者只提供 API,把 SSR 交给 Next / Nuxt。结论是后者。
路由 02
history 模式下刷新,浏览器是真的去请求 /user/42,服务器必须回退到 index.html;hash 模式天然不会 404,因为 # 后面的东西根本没发给服务器。
面试里被问"你们怎么做的 SSR",先答哪一层做的,再答数据怎么过去的,最后答降级怎么办。这三句就够了。
04不要一次做完
同一个思想,在五个完全不同的层面出现
Node 07
Stream 的背压:读得比写得快就把源头暂停,让内存不涨。硬要一次读完一个大文件,进程就直接倒了。
React 15
Fiber 把渲染拆成一个个可中断的小单元,让浏览器有机会插进来处理输入。老版本递归一旦开始就停不下来。
性能 06
长任务切片,每 5ms 让出主线程。同一份工作量,用户体感完全不同——那份材料里有个演示能直接看出来。
扩展 06
Service Worker 空闲 30 秒就被杀。听起来是限制,其实是同一个思路:不让任何东西长期占着资源。
场景 02
大文件分片上传是同一个思想:一次传不完就切开,断了只重传失败的那几片。分片越小重传越省,但请求数和管理成本跟着涨——所以这是个要算的取舍,不是越大越好。
这五件事的共同点:把大任务切成能停下的小块,并且知道哪里可以停。能把这句总结说出来,比分别背五个概念有用得多。
05从"能写"到"能搭"
先定不可逆的 → 再拆能替换的 → 出事先止血 → 最后才谈最优
架构 01
0 到 1 的第一步不是选框架,是把决策按可逆性排队:技术栈、数据模型几乎不可逆,目录结构、命名随时能换。先做贵的那个,可逆的晚点定反而更准。
架构 10
Node 分层只解决一件事:换数据库、换协议的时候不动业务代码。controller 里不写 SQL,service 里不碰 req / res。
Nginx 14
挂了先看清是 502 还是 504:连不上就是进程没了,连上了但没回就是它慢了。一步分叉,省掉一半排查时间。
排查 09
线上出问题第一件事是止血,不是定位——回滚、降级、关掉开关。定位可以慢慢做,用户不能等。
算法 01
手写题也是同一套顺序:先把暴力解写完整让它能跑,再指出瓶颈在哪,最后才优化到最优解。面试官看的是这条路径,不是最终那行代码。
微前端 01
拆的判据不是技术,是组织:几个团队要不要能独立发布。做不到独立部署的"微前端",只是多套了一层壳,成本照样付,收益拿不到。
这六件事的共同点:先做不可逆的决定,把可逆的留到后面,并且在任何情况下都先保住"能跑、能退、能查"。