具象的知识点背后的设计思考

有些题目，知识点你全都学过，就是没写出来。 这道题就是这样。Promise.all 我用过，二分拆数组练习过，递归思路也写过——但坐在那里看着题目，脑子里这三块东西各自飘着，就是没拼在一起。

在写 CSS 的过程中，你可能遇到过这样的困惑：明明没动什么，一个浮动元素突然撑开了父容器；或者费尽心思调 z-index，元素就是不按预期叠放。背后大概率涉及两个概念。

每次面试被问到"React Fiber 是什么"，我都能说出"可中断渲染"这几个字，但一旦被追问"那它怎么中断？中断之后做什么？"就开始语塞。 最近一次深挖让我意识到，Fiber 不只是一个优化方案。

在优化 Web 应用性能时，我发现一个有趣的矛盾：用户希望看到最新的内容，但同时又期望页面加载飞快。这个矛盾的解决方案，就藏在 HTTP 缓存机制中。 那么，HTTP 缓存到底是如何工作的？

最近刷到一道题，业务场景很真实，写完之后发现自己走了不少弯路。 复盘下来有个感受：不是知识不够，是知识的"激活条件"没建立起来。 每一步用到的概念我都学过，但在具体场景里，没能在正确的位置正确地使用。

这类题的难点不是逻辑，是心智模型没建立起来。一旦你理解了"函数包裹"这件事的本质，`withRetry`、`withLimit`、`withDelay`，以及它们的任意组合，都会变成同一道题的不同变体

为什么浏览器要"阻止"我的请求？为什么本地开发时能访问，部署后就不行了？随着对 Web 安全的深入了解，我逐渐理解：这些"限制"不是浏览器在为难开发者，而是在保护用户。这篇文章是我对浏览器安全机制总结

有一段时间我一直搞不明白一件事：同样是"移动一个元素"，用 transform: translateX() 就很丝滑，用 left 就会掉帧——明明做的是同一件事，为什么差这么多？

用了好几年脚手架，npm run dev 一敲就能跑，npm run build 一敲就能部署，但一旦被问到"你知道背后在做什么吗"，我发现自己答得很模糊。这篇是我补课后的学习笔记。

用了两三年 React，我一直对"虚拟 DOM 更快"这个说法半信半疑。直到有一次优化一个长列表卡顿问题，才真正逼着自己把这套底层逻辑摸清楚。这篇是我的学习笔记。

这篇文章的起因很朴素：被面试官问到"浏览器输入 URL 后发生了什么"，我当时答得磕磕绊绊。事后复盘，发现自己其实每天都在和这条链路打交道，却从没认真梳理过它。所以这篇更多是我的学习笔记。

备考面试的过程里，我发现一件有意思的事：很多题目表面上考的是不同的知识点，但解题的起点其实是一样的——先搞清楚题目的结构，再选对应的模型。

这篇文章整理了我在备考过程中归纳出的 6 个前端思维模型。每个模型都有一个"触发信号"——当你在题目里看到这个信号，就知道该用哪个模型了。

`reduce` 是好工具，但它是线性的。二维问题交给 Map，让它做自己擅长的事。工具选择应该跟着数据关系走，而不是跟着操作外形走。

当数据量超过视觉或性能承受范围时，如何决定「渲染哪些、跳过哪些」？只是裁剪的依据不同——Tree 靠用户交互，VirtualList 靠滚动位置。这篇文章是我整理这两道题的学习笔记。

最近在准备面试，翻到几道关于 Custom Hook 的模拟题。表面上看各不相同——轮询、筛选、防抖搜索——但仔细分析之后，发现它们背后有一套共同的思维框架。

性能问题往往不是"用没用这几个 API"的问题，而是对浏览器渲染机制和 React 默认行为的理解是否到位。本篇文章从浏览器渲染的底层出发，一路推导到 React 组件的渲染控制和状态设计。

三道经典的异步编程题：sleep、并发调度器、EventEmitter。分别考察了 Promise 基础，异步控制流和设计模式。与其死记代码。不如把代码的每一行“为什么”搞清楚。

React.memo、useMemo、useCallback 各自解决了什么问题？它们是如何协作的？什么时候该用，什么时候加了反而是负担？面对一个有渲染性能问题的页面，优化的思路和顺序应该是什么？

我曾遇到这样的困惑：花了很多时间优化代码，减少了回流次数，设置了合理的缓存策略，但如何证明页面"变快了"？用户说"感觉还是有点慢"，但我不知道具体慢在哪里。这让我开始思考：性能到底应该如何度量？