每當Go程序編譯出現循環引入報錯的時候就非常讓人頭疼。
那麼，為什麼Go不允許循環引入呢？
我覺得原因如下：
搞清楚package包的定位
首先，搞清楚Go語言中package包的定位；
Go語言的package和其他語言中的庫、模塊是相同的概念，在其他語言中，實現某個庫或者模塊需要建立"單獨的項目"，而在Go中，僅僅是一個包就夠了。
在正常Coding的時候，在我們項目中可以隨便引入外來的項目(例如PHP項目引入PHP包)，但是，我們可以隨意的修改引入的包嗎？不可以！在我們寫PHP的時候，我們可以引外來的包，並在引入的包中做修改，和現有項目循環依賴嗎？更不可以！
從這個角度來講，Go語言不允許循環引入，算是合情合理的，因為Go中的package就是相當於其他語言中的“一個小項目”。
語言設計層面
第二，我們考慮一下，循環引入可能帶來的壞處。
曾經有人提議Go語言作者Rob Pike，想要在Go以後的版本去掉循環引入；Rob Pike堅決不同意。Rob Pike覺得假如你兩個包之間存在循環引入的問題，那一定是你在設計之初就沒考慮好模塊的劃分。
我們試想，假如允許循環引入，那麼，模塊和模塊之間就存在相互的調用，隨著項目的推進，模塊之間的依賴關係越來越多，最後導致倆模塊耦合性變的很高，最初模塊之間的界限變的越來越模糊，最後都偶合在一起了，變的一團糟。一個好的設計，一個好的模塊的劃分，就不應該存在循環依賴的問題！
因此，Go語言在設計之初，就強制要求不允許循環引入，這會迫使開發者在寫代碼之前就考慮模塊與模塊之間的依賴關係，保持依賴關係的整潔。否則，允許循環引入，雖然帶來了coding的方便，但是從工程的長遠角度來考慮，對整個工程的構建、代碼的整潔都是非常不利的。
其他原因
最後一點，禁止循環引入會讓編譯變的更高效。
分享到:
