那么，为什么Go不许可循环引入呢？
我以为缘故原由如下：
搞清楚package包的定位首先，搞清楚Go措辞中package包的定位；
Go措辞的package和其他措辞中的库、模块是相同的观点，在其他措辞中，实现某个库或者模块须要建立"单独的项目"，而在Go中，仅仅是一个包就够了。
在正常Coding的时候，在我们项目中可以随便引入外来的项目(例如PHP项目引入PHP包)，但是，我们可以随意的修正引入的包吗？不可以！
在我们写PHP的时候，我们可以引外来的包，并在引入的包中做修正，和现有项目循环依赖吗？更不可以！
从这个角度来讲，Go措辞不许可循环引入，算是通情达理的，由于Go中的package便是相称于其他措辞中的“一个小项目”。
措辞设计层面第二，我们考虑一下，循环引入可能带来的坏处。
曾经有人发起Go措辞作者Rob Pike，想要在Go往后的版本去掉循环引入；Rob Pike武断不同意。Rob Pike以为如果你两个包之间存在循环引入的问题，那一定是你在设计之初就没考虑好模块的划分。
我们试想，如果许可循环引入，那么，模块和模块之间就存在相互的调用，随着项目的推进，模块之间的依赖关系越来越多，末了导致俩模块耦合性变的很高，最初模块之间的界线变的越来越模糊，末了都偶合在一起了，变的一团糟。一个好的设计，一个好的模块的划分，就不应该存在循环依赖的问题！
因此，Go措辞在设计之初，就逼迫哀求不许可循环引入，这会迫使开拓者在写代码之前就考虑模块与模块之间的依赖关系，保持依赖关系的整洁。否则，许可循环引入，虽然带来了coding的方便，但是从工程的长远角度来考虑，对全体工程的构建、代码的整洁都是非常不利的。
其他缘故原由末了一点，禁止循环引入会让编译变的更高效。
更多精彩内容，请关注我的微信"大众年夜众号 互联网技能窝
