上周我看了一篇讲事件循环的文章。配图、动画、代码示例都齐了，我一路划到底，频频点头。合上浏览器的那一刻，我觉得自己终于把宏任务、微任务搞明白了。
第二天组里有个新人问我：Promise.then 里的代码为什么比 setTimeout 先跑？我张了张嘴，回了句"因为微任务队列优先级高"，然后就接不下去了。他追了一句"那微任务队列是谁在什么时候清空的"，我只能含糊地说"反正就是那样"。
这种场景你多半也有过。问题不在记性，在于"看懂"和"能用"之间，还差着一整个理解层。
看懂不等于学会
我们太容易把"读完了"当成"学会了"。一篇好文章把难点拆开、配上图示，读者顺着作者的思路走，每一步都觉得理所当然。这种顺，是作者替你把路铺平了，不是你自己能走通。
真要检验，得反过来：让你从零讲一遍。讲的时候，哪一步你只能说"就是那样""它本来就这么工作"，哪一步就是你不曾真正理解的地方。
拿闭包举个具体的例子。很多人能写出返回内部函数的代码，也能背出"函数记住了定义时的作用域"。如果让你给一个没学过编程的人讲清楚——下面这段里，每次调用 counter() 拿到的 count 为什么是独立递增的，而不是共用一个——你就得把"词法作用域""函数对象携带环境""调用栈和堆的区别"串成一条因果线。背定义那一步很简单，串成一条能讲通因果的线，才是真懂。
function makeCounter() { let count = 0; return () => ++count; } const a = makeCounter(); a(); // 1 a(); // 2
不少人卡在"为什么 count 没有在 makeCounter 返回后被回收"。这个问题答不上来，就说明你只记住了结论，没理解 JS 引擎怎么处理闭包变量的生命周期。看懂一篇文章不会暴露这个缺口，讲一遍就会。
费曼学习法只有四步
方法来自物理学家理查德·费曼。他看书有个习惯：学完一点东西，就尝试把它讲给一个完全没接触过的人听，讲到对方点头为止。讲卡住的地方，就是他自己知识的缺口。
后人把这套习惯整理成四步。本系列后面三篇会逐篇拆开：
选概念：挑一个你自以为搞懂、但说不清的东西。 讲出来：假装对面是个外行，把它写下来或说出来，别用术语堆砌。 补缺口：讲不顺的地方，回到源头重新学，别绕过去。 再简化：把讲通了的东西压短、加类比，变成你自己的版本。
这四步针对的不是"记不住"，是"以为自己懂了"。后者比记不住更隐蔽，因为它让你在错误的自信里停止了学习。
为什么程序员尤其该用
程序员是"读"的大户。一天里我们读文档、读博客、读别人的代码、读报错栈，输入量极大，但主动"讲出来"的机会少得可怜。写代码是输出，但写代码验证的是"能不能跑通"，不一定验证"讲不讲得清为什么这么写"。
几个具体场景，本质都是"把概念讲清楚"：
面试被追问底层原理，答到第二层就空了。 带新人时，对方问"这段代码为什么这么设计"，你发现自己讲不明白亲手写的逻辑。 技术方案评审，同事问"这里为什么不用方案 B"，你一时接不上。
这些不是表达能力问题，是理解深度问题。费曼学习法给了一套低成本自检：不用等面试或评审来揭穿你，自己讲一遍就露馅。
它还有一个附带好处：技术更新快，单个框架会过时，但"把一个概念讲清楚"的能力不过时。你今年用费曼法学 React，明年用它学 Rust，方法本身可复用，不像具体 API 那样有半衰期。
接下来三篇写什么
本篇是全景。后面三篇各拆一步，每篇配一个你能立刻照做的练习：
第二篇讲"选概念"和"讲出来"——怎么挑一个值得费曼的主题，以及把技术概念讲给外行听的具体写法。 第三篇讲"补缺口"——讲卡壳的地方怎么回到源头（官方文档、源码、最小复现）真正补上，而不是再看一遍二手博客。 第四篇讲"再简化"——怎么把讲通的东西压成一句话、用好类比，最后沉淀成你自己的笔记或博客。
如果现在只想做一件事：下次看完一篇好文章，别急着关标签页，在备忘录里把它讲给"一个完全不懂编程的朋友"听一遍。卡住的那句话，就是你明天该补的课。