尾巴咬到了嘴巴。
引言
從 Java 轉到 Go 的開發同學，大概都會踩到第一個“坑”： Go 的包循環引用。
Go 的包循環引用是什麼意思呢？有一定經驗的開發者都知道循環依賴，比如 A 依賴了 B， B 依賴了 C ，C 又依賴了 A。 這就構成了一個循環依賴（有環圖）。
在 Java 裏面，循環依賴是類級別的；但 Go 裏要更嚴格一些：Go 的循環引用判定是 包級別的。舉個例子，包 A 下的類 A 依賴了包 B 下的類 B，類 B 又依賴了包 C 下的類 C， 類 C 又依賴了包 A 下的 D。 在 Java 裏面，這裏並沒有構成循環依賴。但在 Go 裏面，這導致了包循環引用：包 A => 包 B = > 包 C => 包 A。 Go 會編譯不通過：報 import circle not allowed。
對包依賴不太重視的人，初期會感到不適應。本文舉幾個自己踩過的坑，作一說明。
包循環引用釋例
對象導致的包循環引用
哎呀呀，初來乍到，一下子給我來了八個包循環引用，打擊得我有點不知所措了。這是怎麼回事呢 ？
第一個循環引用，是因爲上報的包 agent 下對象 DetectionBase 依賴了包 denoise 下的降噪模型結果對象 HitDenoiseModel，而在某一處，HitDenoiseModel 又引用了包 agent 下的另一個對象。
爲什麼會發生這個事情？這是因爲，圖省事，我直接把輸出對象放到了輸入對象的包裏，不想複製一份。正確的做法是，輸入的對象只能放輸入對象，不能放輸出對象，否則依賴就會擴大出去。
如何解決？有兩種方案：
-
把 HitDenoiseModel 放在 agent 包下。然後定義另一個對象 denoise/DenoiseResultModel，將 FillHitDenoiseModel 方法移到包 denoise 下，HitDenoiseModel 賦值給 DenoiseResultModel。這樣形成了包 denoise => agent 的單向依賴，保證“輸出 =>輸入” 的單向依賴。不過，這種方法還是存在“篡改”原始數據的小罪行。
-
不對 DetectionBase 做任何變更，新創建一個包和對象，把 HitDenoiseModel 放在新創建對象裏，同時將 FillHitDenoiseModel 方法移到新創建對象的包下。
啓示：避免篡改輸入對象。應用中的對象往往是很多的，不太重視包依賴，很容易造成對象的循環引用。即使你自己能夠小心確保不出問題，也會和別人添加的類造成循環引用。
發送消息與接收消息循環引用
梅開二度。又來了一個包循環引用。
這又是怎麼回事？ 有了第一次經驗，第二次就不那麼慌了。 先提個 MR ，看看引入了哪些類。尤其是循環引用的那條鏈路。 我們看到 cdc/msg 這個地方作爲起點開始循環。爲什麼會有循環呢？因爲我本來打算把 msg 相關的消息對象和消息處理都放在一起。但這種方式很容易導致 循環引用。爲什麼呢？ 因爲 引入消息對象的時候， 就會把包下的所有類引入的所有包都引進來，這樣就會把 /cdc/msg/XXXReceiver 引入，進而引入 /cdc/handler/XXXhandler, 而 msg/handler/XXXhandler 又會引入 msg/XXXSender。 就導致了包循環引用依賴。
看來之前還是隨意慣了。
怎麼解決？ 把 XXXReceiver 放在包 receiver 下，把 XXXSender 放在包 sender 下即可。
啓示：
-
引入類的包要小，這樣就很類似 Java 的全限定性包，減少循環引用的可能性。
-
簡單的消息對象與複雜的消息處理不要放在一起，因爲引入簡單的就會把複雜的引入，複雜的又會遞歸引入更多的依賴。
internal 引用了 share
一鍵三連。
下圖又是怎麼回事？借鑑業界最佳實踐，咱們把一個工程下的代碼分爲了 internal 和 share。 其中 internal 的代碼不能被其它模塊訪問，只有 share 下的代碼作爲橋樑，爲其它模塊提供服務。
這個是因爲 internal/detect_config/AService 引用了 share/detect_config/BService ，然後 share/detect_config/CService 又引用了 internal/detect_config/DService。internal 包怎麼能夠引用 share 下的包呢 ？內部模塊怎麼能夠依賴外部模塊 ？世界似乎不那麼美好了。
與同事討論，他們認爲，helper 不應該依賴 service ，而應該依賴 repository， 而我一直認爲 helper 是對 service 提供服務的一種高層封裝, helper 依賴 service 是很正常。helper 依賴 repository， 看上去說得也很有道理。不過 internal 模塊依賴 share 模塊，看上去總是感覺有點違反單向依賴的設計原則。
經過討論後，我和同事各做了修改。我的修改是讓 helper 依賴 repository， 同事的修改是，把原來 service 拆分成公共的 service 和內部的 service，保證 share 對 internal 的單向依賴。
運行時循環依賴
即使你幸運地逃過了包循環引用的檢測，但存在運行時循環依賴，Go 會直接卡住。
一個例子如下圖所示：有若干個流程組件 A, B, C，加載到一個工廠 F 下，由一個 執行器 E 依次從 F 中取出執行。但是呢，在流程組件 C 中，又依賴了 E 來執行任務。 這樣會導致循環依賴。在 Java 中，Spring 會忽略組件 A， 初始化成功（可以用懶加載機制解決）； 但是 Go 就不那麼幸運了（也許是幸運的，因爲它讓你早點發現問題）。
對於這種場景，可以用消息來解耦。
對策彙總
遇到包循環引用，有哪些經驗可循呢 ？
（1） 提倡小而獨立的包。不要把大量的有關聯的類都放在一個包下。這樣，很容易因爲一個類的引入，而引入更多依賴，導致依賴不可控。
（2）單向依賴原則。internal 下的類不應當依賴 share 下的類。因爲 share 下的類一定會依賴 internal。 如果 internal 又依賴 share ，就破壞了“單向依賴”原則。當工程越來越大時，一定會有一個點會爆發。不是不報，時候未到。 細分包可以緩解這種問題，但不能從根本上避免單向依賴的破壞。
（3）依賴倒置原則。儘量依賴接口，而不是具體實現類。
(4) 使用消息解耦。
（5）相對合理的依賴方向：model => (constants, 無依賴的 model) ; dto => types => constants ； util => (dto, types, constants, models)；service => repository => model ； helper => (repository, util, cache) ; controller => (helper, service) ; receiver => handler => (service, helper)
最後問一句：Go 爲什麼不允許包循環引用呢 ？ 聽聽 Go 語言作者怎麼說：
再聽聽 AI 怎麼說 ：
小結
本文討論了幾個包循環引用的例子，並給出了相應的對策。
個人覺得，這種禁止循環引用的做法還是可取的，能培養良好的設計習慣。軟件開發，本質是應對結構複雜性的技藝。而設計思維，則是應對結構複雜性的重要法寶。開發人員應多多學習設計思考，保持系統和架構的優雅。