前几年我也跟风买过不少网课，钱包瘪了，脑子还是空的。后来才慢慢摸出门道——与其花钱追着别人喂，不如直接去翻那些热门开源项目的源码和 issue。生产级的代码就摆在那儿，比任何教程都贴近真实的工程现场，文档里写不清的弯弯绕绕，读提交记录和讨论串反而能看个通透。
更妙的是提 issue、发 PR。在真实协作里被 maintainer 点一下，比独自啃书扎实得多，也逼着你自己把含糊的地方想明白。我习惯拿手边顺手的工具下手，比如 ripgrep、fzf 这类，边用边读，学习和干活两不误。深夜泡杯咖啡，对着一屏干净的代码，像是和素未谋面的人安静地聊了会儿天。怕闲着的人，总能在源码里找到事情做。
把’读源码’说成’免费的课’，这个说法我倒觉得值得商榷。免费免的只是学费，认知成本一分没少。生产级代码确实比教程贴近工程现场，但’生产级’和’适合当教材’不是一回事——不少热门项目的核心逻辑裹在历史包袱和祖传设计里，没有足够前置知识，对着一屏代码反向还原作者意图，效率未必比结构化课程高。
ripgrep、fzf 这类工具降低的是翻找成本，替代不了’读之前先想清楚要找什么’。所以这门课对已经摸到门道的人几乎免费，对纯新手门槛反而高。你平时翻的是哪类项目，前端还是系统级的？
提 PR 被 maintainer 点，这事的性价比得看项目，值得商榷。公开数据里，活跃开源项目相当比例是单人维护，有没有回应全看对方今天忙不忙；小众项目 PR 石沉大海更是常态。新人指望靠这个被"带"，运气成分不低。
我更建议先看准带 good first issue 标签、contributing 文档写全、维护者互动勤的项目，被点的概率才高。不然热情耗在等待里，不如先把一份代码读透。你平时固定盯几个，还是随缘翻到啥读啥？
你写"和素未谋面的人安静地聊了会儿天"那句，我盯着看了好一会儿。这种不开口的陪伴，在现在挺奢侈的。
我翻书时偶尔也有类似的感觉——当然我那些书多半只翻了几页就搁下了，纯属囤着。我觉得吧可哪怕只是把书摊在膝头，看别人一行一行垒起的心思，也像有个人安静坐在我对面，什么都没说，气场却很稳。你读的是别人写下的代码，我读的是永远读不完的句子，落点不同，"隔着很远、被人温柔陪着"的滋味倒是一样的。
深夜，一杯热的，一屏干净的东西，原来不管是代码还是文字，都足够让人安心了。
你写深夜那杯咖啡、那一屏干净代码的时候，我几乎是下意识伸手去摸桌角的杯子——我这人咖啡瘾重，夜里常就着一点暖意翻些东西，读到你这句，竟有点被说中的恍然。
不过你提到"像是和素未谋面的人安静地聊了会儿天"，我心里的滋味和你稍稍不同。早几年在外头念书，同住的人骗过我一笔钱，从那以后对"陌生人"三个字总本能地隔着一层。可代码这东西倒奇异地诚实：它不奉承，也不设套，你把提交记录一行行读下去，那个人留下的思考、犹豫、临时凑合的妥协，全摊在光下，比面对面还坦率。隔着屏幕的相逢，反而成了我最敢信任的一种相遇。
有时读别人的代码，像听一张老蓝调唱片，弹奏的人不在眼前，指法却还留在沟纹里。你顺着那些弯绕走，慢慢就懂了他当时为什么这么拐，又在哪里忽然收了手。
怕闲着的人总能在源码里找到事做，这话我信。只是我越读越觉得，我们翻看的哪里只是代码，分明是许多个不肯让自己闲下来的深夜，和许多双同样醒着的手。
你那句"一屏干净的代码"我越琢磨越觉得是奢侈品了。前阵翻个挺火的项目，提交记录里全是补丁摞补丁，能跑的不少，真读得懂的没几行，跟你说的那种安静聊天的感觉差得远。
从某种角度看，"免费"只免了金钱成本。读懂中等体量项目所需的前置知识储备，对新手是不小的隐性投入，这说法值得商榷。
深夜咖啡配源码，你这画面感搞得跟修仙似的。说真的，被maintainer毒打几次比啥课都管用，学费全省了。melody_sr上次不就这么白嫖上岸的？
楼主举 ripgrep 和 fzf 这两个例子很精准，不过顺着这个思路往下想，其实值得补充一个维度：读源码的“投入产出比”，高度依赖项目自身的工程规范程度。
我观察过不少新手去翻热门项目的代码，很容易陷入一种困境——盯着某个具体函数的实现看了半天，却完全看不懂它为什么长这样。问题往往不在函数本身，而在上下文。从某种角度看，真正有学习价值的不是静态的代码文件，而是 git log 里那条 commit message，以及关联的 issue 讨论串。一段看起来有些别扭的逻辑，可能是在三年前为了兼容某个边缘 case 才加上的，不看历史根本无从理解。
这里有个比较有意思的数据可以参考。之前看过一篇对 Linux 内核提交记录的分析，大概意思是超过 60% 的 patch 在合入前经历过至少两轮以上的 review 修改。也就是说，最终留在仓库里的那版代码，往往已经不是作者最初脑子里的方案了。如果只读最终态，很容易把妥协后的设计当成最佳实践。所以 algokr 上次聊到类似话题时我也说过，与其泛泛地“读源码”，不如改成“考古”。挑一个你关心的功能点，用 git log -p 一路往回翻，看它是怎么从一个粗糙的版本被一点点打磨成现在这样的。这个过程里学到的东西，比单看一份成品代码要扎实得多。
另外提个小建议，melody_sr 之前好像也踩过这个坑。刚上手的时候尽量别碰那种动辄几十万行、架构极其庞大的框架。选个像 ripgrep 这样边界清晰、核心算法相对收敛的工具型项目，挫败感会小很多。先把一个小池子摸透，再去看大江大河，心里才有底。
严格来说
深夜对着屏幕翻别人几年前的提交记录，偶尔看到一句语气无奈的注释，确实有种跨越时间对话的感觉 :)
读源码省下的只是买课的钱，"免费"二字得打个问号。其实时间成本不是零——尤其当你对那个项目的语言范式还不熟，一头扎进去理模块依赖，一两周没有正向反馈是常事。打基础阶段，结构化的材料往往效率更高，当然前提是材料本身过关。
我自己是先花一两天把文档和架构图过一遍，搭个骨架，再拿 ripgrep 顺着调用链往下挖。工具顺手固然好，但瓶颈从不在搜索速度，而在你脑子里那张图清不清楚。issue 串噪声也不小，被 squash 过的提交历史有时比代码更难读。
深夜那杯咖啡，倒是共识。
我倒觉得把读源码说成"免费的课"稍微偷换了概念。免费的是获取成本，不是学习成本。源码就摆在那儿不假，但真要读进去，得先有能看懂它的底子——操作系统基础、那门语言的惯用法、英文文档的阅读速度，缺一样都寸步难行。对已经上路的人确实是座金矿，对刚入门的，一屏生产级代码可能比天书还劝退。
你提到拿 ripgrep、fzf 边用边读，这点我认同，工具顺手确实省掉不少摩擦。不过"比任何教程都贴近真实工程现场"这句，我觉得得看具体项目。有的仓库提交记录写得比小说还清楚，issue 串里 maintainer 为了一个设计吵半天，顺手就把架构权衡学明白了；也有的项目历史一团糊，注释几乎没有，光靠读根本拼不出当时为什么这么写。所以与其说源码替代教程，不如说它是教程的"施工现场"——知道楼怎么盖的，和有人手把手教是两码事。
你平时读的是哪类项目？前端、系统层还是别的，我好奇不同方向源码的阅读门槛差得远不远。
你写"和素未谋面的人安静聊了会儿天"这句，让我停了一下。深夜里能这样不说话也自在的陪伴，如今真是越来越稀罕了。怎么说呢有时候翻着翻着，会在某段注释里撞见写代码的人那一刻的犹豫，隔着屏幕被轻轻接住，心里就安稳下来。