Spring @Autowired 註解的爭議與最佳實踐建議

Spring 2.0 引入大量註解，@Autowired 成為依賴注入的熱門選擇，但也引發架構師對配置混亂、模組化受損、維護困難、廠商鎖定的擔憂。本文剖析優缺點，給出務實建議。

註解帶來的四大痛點

1. 依賴關係隱性化：XML 顯性聲明 Bean 接線，註解分散在類內部，新人難以全局掌握依賴圖。
2. 模組化裝配受阻：多模組專案需跨模組掃描，配置掃描路徑易衝突，導致 Bean 重複註冊或遺漏。
3. 維護成本上升：尋找依賴來源需跳轉源碼，而非集中查看 XML；重構時易誤刪註解導致運行期錯誤。
4. 遷移鎖定風險：更換 IoC 容器（如遷移至 Guice、CDI）需逐個清理 Spring 專屬註解。

代碼示例：註解與 XML 混用的困境

<!-- 必須註冊後處理器才能啟用 @Autowired -->
<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

<bean id="foo" class="lavasoft.springstu.anno.Foo">
  <constructor-arg index="0" type="java.lang.String" value="aaaa"/>
</bean>

<bean id="bar" class="lavasoft.springstu.anno.Bar"/> <!-- 隱性依賴 foo -->

public class Bar {
    @Autowired(required = true)
    private Foo foo; // 編譯期無錯誤，運行期才知缺失
    public void f1() { System.out.println(foo.getName()); }
}

XML 中 bar 定義看似獨立，實則強依賴 foo，且構造器注入與欄位注入混用，認知負擔加重。

何時適合使用 @Autowired？

• 單一應用、團隊共識強、不預期遷移容器：簡化配置，提升開發效率。
• 測試代碼：單元/整合測試類注入被測組件，生命週期短，遷移成本可控。
• 第三方庫類無法修改源碼：配合 @Bean 方法或 XML 定義 Bean 時，內部依賴可用註解。

推薦策略：XML 為主，註解為輔

1. 核心業務 Bean、跨模組依賴、基礎設施組件（DataSource、TransactionManager 等） → 統一在 XML 顯性聲明，構建清晰依賴藍圖。
2. 內聚模組內部協作類、Controller/Service 實作類 → 可使用 @Autowired / @Resource / @Inject (JSR-330) 降低樣板。
3. 啟用 annotation-config 與 component-scan 時限制掃描範圍，避免誤掃無關類。
4. 建構子注入優於欄位注入：不可變依賴、易測試、不依賴反射設值，IntelliJ 可自動生成構造器。

遷移友好建議

若預期未來可能遷移：

• 優先使用 JSR-330 @Inject + @Named 替代 Spring 專屬註解。
• 將注入點集中在構造器，避免散落在 setter/field。
• 保留 XML 定義 Bean 生命週期、作用域、AOP 切面等容器級元數據。

結語

@Autowired 非洪水猛獸，但「全註解零 XML」屬於極端實踐。成熟團隊應建立分層配置規範：XML 管架構骨架，註解管葉子節點；代碼評審強制檢視依賴圖，防止隱性耦合腐化架構。工具服務於原則，而非相反。