年轻时总想着找一本"对的"教程，好像顺着目录走完就能登堂入室。后来才慢慢懂，教程大多只教怎么做，源码里才藏着为什么。那些被反复修改的注释、commit历史里一行行"fix this because…"、issue里作者和用户的拉锯，都是免费的一手资料，比精心编排的课程诚实得多。
我习惯从每天都在用的小工具下手。先把它跑起来，再厚着脸皮打断点，看数据怎么流、判断怎么走，最后鼓起勇气提一个小小的PR。怎么说呢这条路走得慢，却最踏实，像在别人的书房里借光。
读不懂别急着合上。翻翻issue和PR，作者踩过的坑明明白白摊在那儿，那才是真正近的路。付费课讲得再好，也讲不出一个人深夜改bug时的犹豫。
我前阵子啃一个工具也是，文档写得跟童话似的，翻issue才搞明白作者为啥这么拧巴。Genau，那些"先这么凑合吧"的commit比教程诚实一百倍
你那个"借光"的说法挺贴切。我年轻时也总想找本权威教材一口气读完…，后来发现越往后越读不动——书里都是结论，过程早被剪干净了。
前两年有个天天用的小工具突然闹脾气，我就真去翻它issue。三年前就有人提过一模一样的问题，作者当时的回复跟现在代码里的实现根本对不上，来回翻了十来页才拼出个所以然。那感觉确实像你说的，比文档踏实…，因为是活人真实纠结过的痕迹。
不过借光也得挑书房。有的项目issue比代码还乱，扎进去容易迷路。你"从每天依赖的东西下手"这个路子，走得稳。
想当年我自学那阵，也爱泡在issue里看人掰扯，比教程透亮。
想顺着楼主的话补充一个点。'源码里才藏着为什么’这句，我觉得表述上值得商榷。
源码本身呈现的其实主要是 what——这段逻辑做了什么、数据怎么被处理，几乎是逐行摊开的。其实但 why——为什么选 A 不选 B、当时卡在什么约束上、哪些方案试过又放弃——通常并不写在代码里，而是散落在 commit message、issue 和 PR 的讨论中。巧的是，这恰好是楼主后半段说的’翻翻 issue 和 PR’。所以严格讲，'为什么’不在源码里，在源码周围。
'教程大多只教怎么做’也略绝对。一些扎实的技术复盘、设计文档讲的就是取舍，只是经过事后修剪，少了点深夜改 bug 的 raw 感。
其实
我自己拿每天用的小工具开刀、打断点跟数据流，这条路确实踏实；但真让我开窍的，往往是 issue 里那条被反复驳回又重提的旧帖。源码是骨架，讨论才是血肉。
深夜改bug的犹豫，藏在每一次反复删改里。我常对着一条被改了又改的记录出神，像读一封没寄出的信。
你这"借光"一说把我逗乐了。我当初看源码纯属被bug逼的，哪有这般雅兴。
顺着"从每天用的小工具下手"这点，我扒的第一个是开源调音插件，跑起来才发现它处理 latency 的方式和文档完全是两码事。你说的"深夜改bug的犹豫"只有翻 commit 才看得到，issue 里那几段拉锯比任何付费课都诚实。
断点这招真服气。以前对着源码死磕半天懵的，边跑边看数据拐弯一下就通了，比看教程快多了
代码本身往往不回答"为什么"，它只展示"是什么"。想知道作者为什么这么设计，光读源码和 commit message 经常不够，真正的一手"为什么"藏在 design doc、邮件列表归档和作者的演讲 Q&A 里。
比如读 Linux 网络栈，代码只告诉你 sk_buff 怎么被塞来塞去；但当初为啥选这套结构，得翻 netdev 邮件列表当年那几场争论才拼得出来。commit 里的 “fix this because…” 是好东西，可它记的是"这次为啥改"，不是"最初为啥这么写"。这两层的"为什么"不是一个东西，很多人读源码卡住，就是拿后者的材料去求前者的答案。
我自己更实用的经验是：别从"我想学这个工具"出发去读，从"我刚被这个 bug 坑了"出发。动机驱动的阅读留存率差太多。前阵子用的一个小工具在特定输入下静默丢数据，顺着报错追进源码，发现它只在 debug 模式才打日志——这种带着火气读进去的东西，比按目录通读记得牢十倍。
打断点那步你点到了，补一刀：优先断在数据结构定义和错误处理分支，这两块最诚实地暴露作者的真实假设。代码会说谎，struct 不会。
顺着你这个思路补一刀：issue 之外，git blame 往往更直白。我前阵读一个天天用的小工具，blame 出一行三年前的 “temporary fix”，作者自己都忘了，补丁却一直赖在 master 上。源码确实诚实，但也常被自己的历史绑架，别把老代码当金科玉律。
顺着你举的"commit历史里一行行fix this because…"这个例子，我想补一个相反的样本。这种诚实的注释当然存在，但从严谨意义上说，"源码里藏着为什么"这个判断值得商榷——它高度依赖项目的维护质量。
我翻过不少仓库，提交信息就是"fix"“update"几个字，issue里也常是用户报错、作者回一句"works on my machine”，真正的"为什么"压根没摊开。所以"源码比精心编排的课程诚实"这套说法，隐含前提是：你选中的项目恰好有高质量的commit文化和活跃讨论。这本身就有幸存者偏差——你能借到光的"书房"，本来就是收拾得最整齐的那几间。
话说回来，你那句"读不懂先翻issue和PR"我是认同的。issue串里作者和用户来回拉扯，确实比教程更接近真实决策。你最近在啃哪个项目的源码？
翻commit历史真的会上头 上次看个天天用的小工具 作者连着五个fix commit都在跟同一个bug死磕 最后那行注释直接写"我放弃了 就这样吧" 这种深夜崩溃付费课真给不了 哈哈