前言

相信不少同學都有歐陽這種情況，年初的時候給自己制定了一份關于學習英語和源碼的詳細年度計劃。但是到了實際執行的時候因為各種情況制定的計劃基本都沒有完成，年底回顧時發現年初制定的計劃基本都沒完成。痛定思痛，第二年年初決定再次制定一份學習英語和源碼的詳細年度計劃，毫無疑問又失敗了。

經過多年的摸索，對于如何查看源碼歐陽終于有了一些自己的心得。有的同學還想問英語有什么心得沒，不要問，再問歐陽哭給你看。

一看源碼就頭暈

網上有一種說法是從頭開始看，假如源碼是一個線團，那么找到線團的頭子，順著頭子向下捋就能將源碼了解的七七八八了。

這種方法對于查看小項目的源碼是沒有問題，因為小項目的分支邏輯不多，復雜度也不高，順著線團的頭子向下捋確實能夠搞清楚整個項目。

但是對于vue這種大型項目就不適用了，大型項目里面的分支邏輯特別多，而且每個分支的復雜度也很高。大型項目的源碼就像是一棵樹，那么我們找的線團的頭子只是這棵樹的根節點。

看源碼的時候你從樹的根節點向下走，下面有多個子節點。選了一個子節點接著向下走，結果發現這個子節點下面又有多個子節點。再次選了一個子節點向下走，結果發現還是有很多子節點，重復幾次后你可能就把自己給搞的頭暈了。

出現這個問題的原因是你查看源碼的時候沒有一個明確的目標，因為大型項目的源碼分支流程是超級多的。沒有明確的目標一頭扎進源碼中就會迷失在源碼的海洋中，這個明確的目標就是我們查看vue源碼要搞清楚的問題。

如何接手一個復雜的新項目

想想你平時接手一個不熟悉并且很復雜的新項目你會怎么辦？

我的做法是先查看項目的README.md，了解項目是如何運行起來的。

然后再查看項目的目錄，對整個項目的結構有一點了解。

接著就是找到了解項目的測試或者產品，讓他給我講講項目的大體流程和重要概念，這個時候可能聽不懂或者聽了就忘了，沒關系，有個印象就可以了。

最后就是接到項目的迭代需求，從需求對應的代碼出發開始了解項目。等需求做得足夠多時，基本就將整個項目的代碼過了一遍，此時我們已經完全接手這個項目了。

像接手新項目一樣搞清楚源碼

我們這里以vue舉例，vue其實也是一個普通的js項目。本質上和我們的工作中接手的新項目沒什么區別，對于查看vue源碼我們也可以復用上面這個套路。

第一步：查看contributing.md文件

查看源碼的contributing.md文件，這個文件就像是我們項目中的README.md。開源項目希望更多的人參與進來所以一般都會有個contributing.md文件。這個文件里面會教你源碼項目是如何跑起來，項目結構是什么樣的，怎么參與進來開發。

第二步：查看源碼結構

第二步和接手新項目是一樣的，查看vue源碼的目錄，讓你對整個vue源碼的結構有一些了解。

第三步：對源碼大體流程和重要概念有初步印象

到了第三步就有問題了，不可能叫尤大充當測試或者產品的角色過來給我講vue的大體流程和重要概念吧？此時我們可以換個思路，網上有很多講解vue源碼的文章或者書籍。可以讓這些源碼文章或者書籍充當測試和產品的角色。通過閱讀這些vue源碼文章或者書籍，你就能對vue的大體流程和重要概念有了初步的印象。

網上的文章都參差不齊，如何挑選出優質文章呢？

以掘金為例，你就在掘金上面去搜索vue源碼。然后找出時間最近的，點贊和收藏最多的文章，這樣找出來的文章基本都是優質且未過時文章（墻裂推薦歐陽的vue源碼文章）。

當然如果你在之前沒有接觸過vue源碼，第一次看vue源碼文章或者書籍可能看不懂或者比較吃力。沒關系，我們這一步只是讓你對vue源碼有個初步的印象就可以了。

第四步：帶著問題去debug源碼

直到這一步之前我們所做的事情都是讓自己對源碼有個大致的印象，最終想要看得懂源碼還是得要自己上手去debug。

做項目時我們是通過不斷的做業務需求，從而了解整個項目。在vue源碼這里就是從一個你想要了解的具體問題出發，通過debug調試vue源碼將這個問題搞清楚。這個問題就是我們在查看源碼時的目標，和這個問題不相關的源碼全部都忽略。

這種情況你帶著問題去debug查看源碼，此時的源碼對于你來說就不是一棵樹了，而是圍繞著這個問題的一條線。我們的目標也很單純，只是將這條線上面的源碼搞清楚就行了。當你把這個問題搞清楚了后，在你的腦子里面關于vue源碼就有一條線了。

還有一個進階玩法，將“通過debug源碼把某個問題搞清楚的過程”用自己的話說出來，這就形成了一篇優秀的源碼文章，歐陽的所有源碼文章都是這樣寫出來的。

每個問題在我們腦子里都是一條關于vue源碼的一條線，當我們搞清楚足夠多問題時，這些線連到一起就形成了一棵vue源碼樹。

看到這里有的小伙伴就有疑問了，那么問題又從哪里來啊？

我們每天寫代碼就在用vue，vue提供了很多黑魔法，難道你對這些黑魔法不感興趣嗎？

舉個例子，在vue的文檔中有寫defineProps是一個宏函數。所以我們使用他的時候不需要從vue中import導入，那么你有沒有好奇過為什么他不需要從vue中import導入呢？

為了搞清楚這個問題，我們需要先找到線團的線頭子。而這個線頭子毫無疑問就是@vitejs/plugin-vue插件，vue文件就是由這個插件處理的。給這個線頭子打上斷點，順著斷點向下走，只關心和defineProps相關的代碼。最終我們就找到在一個compileScript函數中，會將源代碼中的defineProps宏函數給remove掉，并且同時會生成一個props屬性，由于defineProps宏函數經過編譯后已經被remove掉了，所以就不需要從vue中import導入。

我們知道vue是一個編譯時和運行時同時存在的框架，編譯時說白了就是代碼運行在nodejs階段，運行時代碼跑在在瀏覽器中。所以在debug源碼的時候有時是在編譯時進行，有時是在運行時進行。

在接下來的文章中我們會給你講一些編譯時和運行時debug源碼的小技巧，如果你有更好用的技巧歡迎在評論區留言。

編譯時debug源碼小技巧

想要在編譯時debug源碼，首先我們需要啟動一個debug終端。這里以vscode舉例，打開終端然后點擊終端中的+號旁邊的下拉箭頭，在下拉中點擊Javascript Debug Terminal就可以啟動一個debug終端。

圖片

在debug終端執行對應的啟動命令，比如yarn dev，斷點將會停留在我們打斷點的代碼處。此時會有這樣一排操作按鈕，如下圖：

圖片

上面的一排操作按鈕歐陽平時debug源碼時一般就使用了前四個，分別是：Continue（繼續）、Step Over（單步跳過）、Step Into（單步調試）、Step Out（單步跳出）。

• 第一個按鈕Continue（繼續）：點擊這個按鈕后會讓代碼執行到下一個斷點。
• 第二個按鈕Step Over（單步跳過）：執行到下一條語句，如果下一條語句是函數，不會走進函數內部。
• 第三個按鈕Step Into（單步調試）：執行到下一條語句，如果下一條語句是函數，將會走進函數內部。
• 第四個按鈕Step Out（單步跳出）：跳出當前函數內部，斷點將會走到外部調用當前函數的地方。

不一定每個問題你都能找到對應的線頭子，這時你就不知道從哪里開始打斷點了。比如還是defineProps宏函數，假如你不知道應該從@vitejs/plugin-vue插件開始打斷點，那這種情況我們應該怎么辦呢？

答案很簡單，在源碼中去搜索defineProps關鍵字，將搜索到的結果都打上斷點。然后啟動項目，發現代碼走進了我們打的斷點中，如下圖：

圖片

此時左側的Call Stack調用棧就能派上用場了，他里面存了當前函數的所有調用棧。比如當前斷點是停留在processDefineProps函數中，從Call Stack調用棧我們就能知道這個函數就是由compileScript調用的，而compileScript函數又是由resolveScript函數調用的。并且可以通過點擊函數名就可以跳轉到對應的函數中，并且恢復當時的上下文。

整個Call Stack調用棧是一條線，我們要找的問題的線頭子就在這條線中。我們帶著問題去debug源碼的時候只需要將在Call Stack調用棧中，線頭子后面的一系列函數邏輯搞清楚就行了。

運行時debug源碼小技巧

大家都知道vue文件經過編譯后會變成js文件，那么如何找到編譯后的js文件給他打上斷點呢？

圖片

很簡單在network面板中找到對應的請求，這里我想找的是index.vue文件。然后右鍵，在彈出的菜單中選擇第一個Open In Sources Panel。瀏覽器將會切換到source面板中，并且自動打開編譯后的index.vue文件，然后我們就可以在這個文件中給對應的代碼打斷點。

關于Continue、Step Over這幾個按鈕，還有Call Stack調用棧都是和編譯時是一樣的，在這里我們就不贅述了，歡迎補充其他小技巧。

總結

大型項目的源碼可以理解為是一棵樹，如果我們直接從樹的根節點開始去看源碼肯定會被源碼的各種分支邏輯搞的頭暈。此時我們可以換個思路，按照以下四步去查看源碼：

• 查看源碼的contributing.md文件，這個文件里面會教你源碼項目是如何跑起來，項目結構是什么樣的，怎么參與進來開發。
• 通過查看源碼目錄讓你對源碼結構有個初步的印象。
• 通過查看源碼文章或者書籍讓你對源碼大體流程和重要概念有初步印象。
• 帶著你想要了解的問題去debug調試源碼，和問題不相關的源碼全部忽略掉。此時的源碼就不再是一棵樹，而是一條線，我們只需要將這條線的源碼搞清楚就行了。當我們搞清楚足夠多問題時，這些線將會匯聚成一棵樹。