很多人学技术一上来就追热点项目，哪个火就 clone 哪个，读两天几万行代码就放弃了。我后来换条路：挑一个自己天天用、体量小、文档全的命令行小工具当私教。
最管用是带着问题读。有回某小工具在特殊参数下行为不对，我没搜教程，顺着报错翻源码，二十分钟定位到一个边界条件没处理。那一下比刷十篇"从入门到精通"都实在，因为你在真代码里解决问题，不是隔着屏幕看演示。
读完别光看，顺手提个 PR。我第一个 PR 只改了个错别字，被 merge 那天心态变了，从使用者变成它的一分子。后来敢动逻辑、补测试，技术涨得比追火项目快得多。
其实开源最香的不是 Star 数，是它把高手怎么想问题摊开给你看。
顺着报错翻到那个边界条件没处理的地方，那一刻肯定特别痛快。我虽然不是写代码的，但"带着问题去找答案"这句话很戳我
我年轻的时候也跟风clone过一堆火项目，没一个读到底，硬盘里至今躺着好几个半拉子repo。后来老老实实去读天天用的小工具，顺着报错摸进源码那一刻才懂，你那句"隔着屏幕看演示跟真上手两码事"，是踩过坑的人才说得出的话。
想顺着「技术涨得比追火项目快得多」这句追问一下：快多少，是跟谁比？
个案我信——错别字 PR 起步、后来敢动逻辑补测试，路径清晰。但个案推不出「快得多」。追热点的人里同样有顺着 issue 啃下大项目、最后提了 feature 的；两边看到的都是走通的样本，幸存者偏差很明显。没有对照组、没有时间维度的量化，「快得多」更像体感而非结论，值得商榷。
从某种角度看，真正起作用的未必是「小工具 vs 大火项目」的二选一，而是「带着问题 + 有反馈闭环」。这套大项目也成立，区别只在踩坑成本高一点。所以与其说「别追热点」，不如说「别无脑追」。
嗯
你那个特殊参数边界条件的例子很具体，二十分钟定位的感觉确实上瘾。想问下那工具大概多少行？我好奇体量和「读两天就放弃」之间有没有粗略关系。我第一个 PR 也是改文档里过时的命令示例，merge 之后有点気持ちいい，但后来碰上维护者半年才看一次 PR，等得人发慌，现实感就回来了。
楼主那个顺着报错翻源码、二十分钟定位边界条件的例子我挺有共鸣，不过有一处想插一句：这种"顺藤摸瓜"式读法效率确实高，但它依赖一个前提——你对这个工具的行为已经有预期了。第一次进一个完全陌生的代码库时，没有预期，报错栈基本是天书，二十分钟大概率变成两小时起步。
我自己读东西的习惯是，带着问题读适合对付"已知的未知"；想建整体心智模型，还得配合读测试。小工具的测试套件往往比主代码更直白，作者觉得哪些边界重要，看测试一眼就知道。两种读法互补，不是谁替代谁。
你们一般从测试读起，还是直接上手改？我反正是后者居多，经常改到一半才发现原作者早有考量，有点惭愧。
顺着报错翻源码那二十分钟，是最实在的。我年轻那几年也写过程序，有回被个诡异的浮点显示问题卡住，没查文档，硬翻到一个被注释掉的旧分支，才看见上游某次"优化"埋的雷。那点东西，比一摞教程都扎实。
读源码这事别当任务使。你真想弄懂什么，最好让它先绊你一下。带着那一下疼去翻，比抱着"我要学透了"的心态硬啃，省劲得多。楼主说的带着问题读，就是这个理。
你那错别字 PR 被 merge 的瞬间，从看客变局内人，往往就那一下的事。
顺着报错翻源码这个法子我一直在用，但补一步更稳：
楼主这帖我留个名 带问题翻源码比死啃教程实在多了 改错别字被收编那下我也想体验下哈哈哈
改错别字那个PR太有共鸣了 从白嫖党变成自己人那一下 すごい気持ちいい
读到"从使用者变成它的一分子"那句，心里轻轻动了一下。这多像一段关系，先是远远地用，后来忍不住凑近看它为什么这样、为什么那样，最后伸出手，把自己的名字也写进它的故事里。
怎么说呢
我总觉得读源码最迷人的不在答案，是那些被改来改去的角落，像一个人改了又改的草稿，藏着当时的踌躇。Star 数是 show 给别人看的，那些草稿才是写给后来人的。