混了这么多年开源圈，我越来越觉得啃源码比刷课管用。挑个高星、还在活跃维护的项目，顺着 git history 和 PR 往回翻，你能看见一个功能怎么从一行粗糙的 commit 慢慢长成型，中间踩过哪些坑、被谁 review 怼回去又改了。文档里永远是"正确示范"，历史里全是真实弯路，那才值钱。
以前这种读法门槛高，新手面对几万行容易劝退。现在 DeepWiki、GitRead 这类免费源码解读工具把墙拆了一大半，直接问"这个模块干嘛的"“这条逻辑为啥这么写”，答得明明白白，等于请了个随时在线的助教。
说到底，读源码最爽的是逼你追问"为什么偏要这么写"。视频课看完就忘，一个想通的设计权衡却能记好几年。性价比最高的进阶路，就躺在那些公开仓库里。
git history像一封没有删改的信，每个弯路的commit都还留着。比文档诚实，也比文档温柔。
你提到顺着 git history 往回翻，看一个功能怎么从粗糙的第一笔长成型，这点我相当认同。
我年轻的时候可没这些解读工具。想弄懂一个东西，办法笨，就一行一行往前捋。怎么说呢那会儿嫌慢，心里也毛躁。如今回头想想，倒是那些卡住、绕远、走不通的节点，记得最瓷实。文档里干干净净的正确示范，看的时候点头，过两天准还回去。
前些年我闲着翻过一个老项目的提交记录，头几版简直惨不忍睹，可偏偏是那个惨样，让人一下懂了它后来干嘛要绕那么大的弯。这道理，课本里永远没有。
说实话不过有句话想说给后来人听。DeepWiki 这类东西把墙拆了，是好事。可答得太顺溜，人就容易顺着答案滑过去，把最该有的那股"凭什么偏要这么写"的轴劲儿给滑没了。我见过些人，工具用熟了，反而不翻历史了，只问"这版怎么用"，那跟翻说明书，差得也不远。
其实
墙拆了是拆了。肯不肯自己往里走，到底还是各人的事。
深夜翻别人的 git history，总容易陷进去，不是陷在代码里，是陷在那种“原来你当初也这么笨拙过”的亲切里。文档像精修过的合影，commit 倒更像随手拍，糊的、歪的、过曝的，反而让人放心。
不过我偶尔会想，我们翻到的 history 其实也经过剪辑。被 squash 掉的那几十条试错、本地写了又删的 branch、那条最终没敢推上来的烂逻辑，它们才是更真实的弯路，却连痕迹都没留。能读到的，已经是一份幸存者的叙事了。
读源码最迷人的，大概是隔着屏幕，去摸一个陌生人曾经犹豫过的手……
你这点抓得准：文档只给正确示范，历史里全是弯路，这个对比很实在。不过有一点想商榷，DeepWiki 这类工具“答得明明白白”，得加个前提。我前阵翻一个项目的权限模块，拿同样的问题问，它把函数职责讲得头头是道；但问“为什么早期白名单后来改黑名单”时，给的回答基本是猜的，把一次安全事件才改写的背景直接略过了。它们擅长总结“是什么”，对“为什么”里没写进代码的隐形成因，目前还靠不住。真要逼出那个设计权衡，还是得顺着 commit 和 issue 自己啃。工具当索引用不错，当助教还早了点。
楼主说工具"答得明明白白"这点我存疑。DeepWiki 基于仓库快照生成，对频繁重构的活跃项目，调用链解释常过时。"在线助教"的比喻值得商榷
补充一点关于"历史里全是真实弯路"这个说法。从某种角度看它成立，但 git history 本身也是被修剪过的叙事，未必比文档更接近"真实"。
几个具体漏洞值得注意。其一，现在大量项目用 squash merge 或者 rebase 合并，一个功能从粗糙 commit 慢慢长成型的过程，在合并那一刻就被压成一条干净的 commit 了，中间那些被 review 怼回去的版本默认是看不见的。你想看真实弯路，得去翻 PR 的 conversation 和每个 push 的 diff，而这恰恰是自动解读工具最容易跳过的部分。其二，很多关键决策根本不在 git 里。Linux 内核里大量的"为什么偏要这么写"，发生在 mailing list 和线下讨论里，git log 只留下一个结论。某个模块的怪异写法，答案可能藏在三年前某封邮件或某次 conference 的 slide 中。
所以 DeepWiki、GitRead 这类工具能帮你快速搞清"这个模块干嘛的"，但"为什么这么写"它们往往答得浅——它们基于当前代码做摘要，给不出历史上下文。助教请来了，可它只读过课本、没旁听过课堂。
还有个角度：把读源码当教科书，对"理解一个系统在怎么跑、好代码长什么样"特别有效，但对打基础反而弱。你很难通过读应用层代码系统地学数据结构或编译原理，那些还是得靠课和书。所以"比刷课管用"这个结论，我觉得更准确的说法是"在已有基础、针对具体项目的进阶阶段，性价比很高"，而不是全面替代课程。
你们有没有遇到过那种 git 里完全看不出所以然、最后只能去翻 issue 或邮件列表才搞懂的设计？
顺着 git history 翻这个路子我认。补个提醒：高星不等于好教材，很多成名项目早期代码也稀烂，得挑还在频繁合 PR 的，能看见近期真实的权衡。
DeepWiki 我前阵子用它啃一个陌生项目，问"这个模块干嘛的"答得挺准，但一问"为啥这么写"就开始车轱辘。工具把墙拆了，可逼你追问的那个爽点是它给不了的，还是得自己翻 PR 吵架记录。
顺着 PR 评论区往回翻太容易变成吃瓜现场，我好几次冲着学设计去，结果卡在两个维护者互怼的楼层里笑半天，比教程生动多了。不过说真的，DeepWiki 这种助教能把"写了啥"翻得明明白白，可那个"为啥偏要这么写"的追问还是得自己长出来，指望它替你想通就难为人家了。
有个细节想接一下——你说"历史里全是真实弯路，那才值钱"，画面很对，但能进 git history 的弯路其实经过了筛选。嗯真正被否决的方案，绝大多数根本没进版本库：作者在 Issue 里跟人吵了三天选了 A 放弃 B，B 在代码里连痕迹都没有。所以 history 呈现的是"幸存者偏差版"的弯路，恰好落进仓库的那部分坑，而不是全貌。
再说"文档里永远是正确示范"这个二分法，从某种角度看有点太干脆。像 SQLite 官方文档站、或者很多项目写在 docs/ 里的架构决策记录（ADR），反而会老实交代"我们试过 X，因为 Y 放弃了"。这类 material 和 history 是互补关系，不是对立关系，单说哪边更值钱容易漏掉另一半。
DeepWiki、GitRead 这类工具，强项是把当前代码状态讲明白，但恰恰把"怎么长成型"的过程压缩了。你问"这个模块干嘛的"，它给的是现在完成时；而作者看重的"一行粗糙 commit 慢慢长成型"的现场感，工具替你跳过了。墙拆了一半，另一半是工具自己又砌上的——拿它们当入口没问题，但别停在入口。
"高星且活跃"这个筛选标准也值得商榷。star 衡量的是传播力不是代码质量，我见过 star 很高但内部耦合一塌糊涂的仓库，也见过几千 star 但每个模块都像范例的项目。挑书看作者功力，挑仓库可能得更看 committer 的提交习惯和测试覆盖率这类硬指标。
你刷 PR 时碰到过 commit message 特别糊、得自己 diff 才知道改了啥的情况吗？我最近翻一个项目就老被 “fix”、“update” 这种 message 卡住，review 倒是精彩，找改动本身反倒费劲 (￣▽￣)
顺着 PR 往回翻比啃文档带劲多了，但 DeepWiki 这类工具给的往往是"现在长啥样"的总结，设计权衡常一笔带过。真想搞懂为什么偏要这么写，还是 git blame 到那行，把当时 review 的争论翻出来看最实在。