我一直想回答這個問題，但是由於我的答案是軟體開發相關的，比較小眾，怕別人很難理解。現在這個關於Spring的問題的回答就算是我對這個問題的回答吧。

軟體開發的一個亙古不變的方針策略就是抽象、透明和封裝。語言從彙編到面向過程到面向物件，開發從原生程式碼到類庫到框架，都是這個趨勢。別說軟體開發了，就說軟體使用吧，從DOS命令列到GUI圖形化介面，也是這個方向。

抽象、透明、封裝就是不讓你陷入到底層的細節當中，把精力專注在你那一層面的問題上。什麼叫你那一層面的問題？你開發產品或者專案，就把精力用在實現業務需求上。並不是底層不重要，而是沒必要到一開始就去看底層原始碼的地步！

我想先問一下題主和有些答主，http://spring.io上的文件你們都讀了幾遍了？

所有專案的文件讀不過來沒事，spring framework這一個專案的reference有完整從頭到尾讀一遍的嗎？然後再來問怎麼閱讀spring原始碼，或者回答人家如何閱讀spring原始碼。

詳細認真讀過spring所有專案的reference，並對所有API doc瞭如指掌的人都少之又少。你先開始讀原始碼幹嘛？說明書和各種電器引數都不看就想把家裡的電視拆了研究的，只能是熊孩子幹出來的事。我見到太多簡歷裡面寫閱讀Linux原始碼的，這些人無一例外都是浮躁型的。

不建議讀框架的原始碼，如何實現一個框架和如何用框架實現業務有很大的不同，在閱讀底層框架原始碼上的時間精力投入相比收穫來說不划算。

只有下面三種情況，你可能需要閱讀原始碼：

你打算髮明一個類似Spring Framkework一樣的框架，可以參考原始碼。你自認為發現了Spring的一個Bug，並提交到官方的Issues list，且得到確認。而你想貢獻自己的力量幫助Spring團隊解決這個Bug。不過在你發現疑似Bug的時候，最好先去Issues list裡面或者stackoverflow上找一下答案再說。以目前Spring的健壯性和被廣泛採用的程度，幾乎沒有可能有一個Bug被你撿漏。Debug跟蹤進入底層框架程式碼的時候，不得不看兩眼。

反過來想想，如果什麼框架要你必須閱讀原始碼才能掌握，那這個框架一定很爛、不成熟，或者說至少處於成熟的前期。

為什麼這麼說呢？像Google、Facebook、Microsoft等大廠，開源專案是專職團隊做的，是有專門的文件編寫和社群關係維護人員的。但有些開源團隊確實是幾個大牛用業餘時間在做。沒有專職的文件和公關人員。他們前期的精力肯定是要放在開發框架本身上。框架基本滿意了，才開始考慮文件，然後還可能順手把網站也搞漂亮點。Spring和Hibernate很早很早以前都是屬於這種情況。

我把話說直接點吧：所有跳過文件這一步就想直接閱讀底層原始碼的，只能是英文水平不行，讀不懂文件又急於求成。想給自己的簡歷或平時的談資加點料而已。在沒有正確的學習路徑下，一時不知道如何提高自己又心急的人，很容易想到的就是去讀底層原始碼