Unity 依賴注入陷阱：循環引用的四大典型場景與規避策略

循環引用：隱蔽的運行時殺手

構造函數注入、屬性注入、方法調用注入均可能引發循環依賴。Unity 在解析時會陷入無限遞歸，最終導致棧溢出或死循環。最佳防禦：編碼階段通過設計規避，而非依賴容器檢測。

四大典型循環引用模式

1. 構造函數注入：雙向依賴

public class Class1 {
    public Class1(Class2 test2) { } // 依賴 Class2
}
public class Class2 {
    public Class2(Class1 test1) { } // 依賴 Class1
}

解析 Class1 → 需 Class2 → 需 Class1 → 無限遞歸。

2. 構造函數注入：自我依賴

public class Class1 {
    public Class1(Class1 test1) { } // 參數為自身類型
}

直接導致無限自我構造。

3. 方法調用注入：雙向方法調用

public class Class1 {
    [InjectionMethod]
    public void Method1() { Method2(); }
    [InjectionMethod]
    public void Method2() { Method1(); }
}

容器調用 Method1 → 觸發 Method2 → 再觸發 Method1 → 死循環。

4. 屬性注入：雙向屬性獲取

public class Class1 {
    [Dependency]
    public string Property1 { get { return Property2; } }
    [Dependency]
    public string Property2 { get { return Property1; } }
}

解析 Property1 → 讀取 Property2 → 讀取 Property1 → 無限遞歸。

規避原則與檢查清單

1. 依賴方向單向化：高層模塊依賴抽象，低層實現抽象，嚴禁雙向具體依賴
2. 構造函數參數審查：避免直接或間接引用自身類型
3. 注入成員最小化：僅標記真正需要的依賴，減少圖複雜度
4. 引入中介接口：打破循環鏈，如引入 IMediator 統一協調
5. 延遲加載/工廠模式：將循環依賴轉為運行時按需獲取（Lazy<T> 或工廠委託）
6. 單元測試驗證圖解析：啟動時完整解析對象圖，暴露潛在循環

Unity 不提供循環檢測機制，開發者需通過架構治理從源頭消除風險。