很多人学新东西第一反应是找教程、报课。我反过来，先把项目跑起来，再顺着依赖树往下翻。

去年想搞明白响应式原理，没去啃文档，直接打开一个用了 Vue 的小项目，从入口一路点到 reactivity 模块。看不懂的就往那个包的仓库跑，看 issue 里大家怎么吵、commit message 怎么写。

收获比看十篇博客实在：知道作者为什么这么设计，而不只是怎么用；遇到坑能直接翻源码定位，不用干等回复；顺手给文档挑错提个 PR，逼自己读得更细。简单说简单说

现在带新人也这么建议：别怕读不懂，从你用得上的那一层开始往下剥。开源最便宜的学费，就是别人的代码摊在那儿等你翻。

顺着 commit history 往下翻确实是捷径，但有个现实坑：现在很多仓库默认 squash merge，主线里就剩一句 “fix typo”，想看设计演进得直接 git blame 到那行再跳 PR。

笑死 这学法绝了 我搞不懂啥东西也爱直接上手乱点 看教程反而越看越困 别人的东西摊那儿随便翻真香

顺着依赖树往下翻这思路我认同，不过有个前提值得商榷：webpack、vite 这类打包器普及以后，从跑起来的项目里点进 DevTools，落到的多半是编译后的模块，不是你想读的源码。要读懂设计意图，还是直接 clone 那个包的仓库对着未打包版本看更准，再顺着 issue 和 commit 反推作者思路。

顺着依赖树往下剥我也在用，但"别人的代码摊在那儿"得打个问号。不少传递依赖是没注释的胶水层，翻不出设计意图。从用得上的那层往下走，得先有个具体问题，否则容易迷路。

你顺着入口点进 reactivity 的时候，用的是项目锁文件里钉死的那个版本，还是直接看的仓库默认分支？这点其实值得商榷。

不少项目依赖的版本和你在 GitHub 上看到的 latest/main 早就分叉了。我前阵子跟着一个库往回剥，本地 node_modules 里的实现对不上文档，更对不上仓库 HEAD，耗了快一小时才定位到是个两年前的 minor 版本。从某种角度看，动手翻源码之前先 pin 住版本号，比一头扎进仓库更省那笔"学费"。

另外你对 issue 和 commit message 的依赖我有点保留。热帖里的争论常常只代表当天的立场，最终合进去的方案往往悄悄改了方向——拿它当"作者为什么这么设计"的证据，容易把历史噪音读成设计意图。真要追问 why，design doc 或 RFC 通常比 issue 串靠谱。其实

当然从你用得上的那层开始往下剥，这个方向没问题。你当时没被版本号坑过？

前两天翻旧代码，突然看见自己三年前在 package.json 里留的注释：“此处 await 之后应加防抖，但先让月亮升起来吧”。现在重读，竟觉得那晚的月光比 debounce 的实现更诚实。

顺着依赖树往下走，像提一盏纸灯笼探古井——越深，水影越晃，倒映的却不是自己，是无数个写过同一行 import 的人。他们留下的 commit message 是井壁青苔，issue 里的争吵是水底游动的碎银。

lazy97说“从你用得上的那一层开始剥”，我倒想起小时候剥橘子，总想先撕掉最外那层白络，结果指尖发涩，汁水四溅；后来才懂，顺着纹路轻轻一掐，瓣与瓣之间自有松脱的余地。

你试过在深夜 PR 里写一句“感谢作者，这行注释救了我”吗？

看issue里大家吵比博客带劲多了 我刷一天都不腻 楼主这法子绝了 从用得上的那层往下剥太对胃口

楼主说的看 issue 里大家怎么吵，这句我倒是觉得整篇里最实在。我年轻时候摸门道也是这个路数，手里有个现成的东西，先拆开看它怎么转，转不明白的地方再去翻它为什么这么造。能吵起来的地方，多半是设计上真没兜住，比文档里那几句漂亮话耐看。

仔细想想现在的年轻人有这福气，代码就摊在那儿随便翻。我那会儿想弄明白点东西，得厚着脸皮四处打听，还未必问得透。不过顺着依赖树往下剥是痛快，也别剥太深迷了路

我当初搞懂一个状态管理库也是直接 clone 下来顺着 import 翻的，比看官方 tutorial 快太多。唯一踩的坑：别顺着 transitive deps 一路追到底，给每层设个红线，追到能解释你手头那个 bug 就收手，不然一下午全交代在 node_modules 里了，literal rabbit hole。

延毕那年顺着引用链读论文，倒把"往下剥"这习惯练出来了。补一条：commit message只看活跃仓库的，死仓库的没参考价值。