说实话我不太建议学习阶段用开源项目作为学习材料

一来很多开源项目架构真的太复杂没法入手
二是学习阶段并没有能力分辨库质量好坏

业务代码就更别看了，世界上没有几行业务代码是精炼过的

我编程学得很早，但也是工作后才逐渐看得进开源大项目的代码的。因为写业务代码会有人告诉你整个系统的架构包含哪些部分和抽象层次，我们现在正要写的东西在哪一层什么功能；你可以从两三个文件入手逐渐摸到整个系统的其它部分。

读代码有点像走迷宫，你得有一个起点然后摸着墙（沿着调用关系链）走，一个文件里包含的数十个函数像是迷宫里并排的几个通道，你看过去了好几个通道（函数），但很可能跟你要走的这条（ API 的调用链）并没有什么关系，会晕是必然的。



个人经验是如果真要评估一个库或者开源项目，就从它的 quick start 或者 bootstrap 看起，观察都有哪些 essential 步骤，每个步骤的目的是什么，然后你自然会考虑每个步骤能不能实现我要的更多需求或目标，逐渐翻阅官方文档和实现，就能慢慢理清楚一部分了。

好的项目模块之间都是很松散的，你完全可以只理解你需要的一小部分然后马上开始针对这一部分做修改。

我只看了一周 vue 的文档也能重写一遍 element plus 的组件——前端组件的组织单位是很小的，一个组件只有几个文件，尽管整个库非常大，但理论上来说我都已经能贡献新组件的代码了，无非是照着原样把文件布置好而已，库的规模并不影响你 **先认知一小部分** 。我想学到一个预期功能需要哪些界面元素、绑定怎样的数据结构、暴露哪些部分，那我其实只需要找到一个组件来看对不对

我也看了很大一部分 gorm 的代码，gorm 充满了各种 interface{}接口和 function dispatch table ，要直接啃源码我敢说根本不可能有几个人能看下来。但如果你只跟着一个 Create 函数进去就会发现结构其实很清晰：一层链式 API 接口，里面一层通用数据结构处理过程（判断 session 、配置、寻找构建器、判断传入值类型等等），再里面一层 clause 构建器（ create 的构建器），再里面是按数据库划分的「构建 driver 」，然后在比如 mysql 的「构建 driver 」里就能看到它怎么拼接 create 和值的字符串、它做了哪些判断和额外操作。这个过程如果我看到不科学的地方比如对关系字段的处理不够好，那我也能开始着手自己的修改。尽管我现在对 ALTER 都干了什么还一无所知，但我已经掌握这个库的一部分架构层次和设计概念了，无非是时间和取舍问题没有对库里所有的东西都摸全覆盖全而已

还有那种更大型的微服务项目，尽管整个项目的体量看起来非常吓人，但你可以先研究脚手架都能干什么、它生成了什么东西，然后搞明白一个 service 单位包含哪些东西。再去寻找猜测可能实现你想找的东西的 service ，逐渐拨开抽象层和数据结构，怎样都是能看进去一部分的