Java 工程中通常使用 maven（當然也有很多人使用 gradle）來管理項目依賴。maven 這樣的構建工具極大的提升了工程的構建效率，我們只需

Java 工程中通常使用 maven（當然也有很多人使用 gradle）來管理項目依賴。maven 這樣的構建工具極大的提升了工程的構建效率，我們只需要把相關依賴添加至配置文件即可，完全不用關心構建的過程。

在以前的文章中maven 中 dependencies 與 dependencyManagement 的區別介紹過關于 dependency 相關的用法，我們知道可以通過 dependency 將依賴添加至 pom.xml 文件中。不過在閱讀其他項目的代碼，尤其是一些組件端的代碼的時候，會發現類似于下面這樣的用法：

<dependency>n <groupId>some.company</groupId>n <artifactId>project-c</artifactId>n <optional>true</optional>n</dependency>nn<dependency>n <groupId>some.company</groupId>n <artifactId>project-d</artifactId>n <scope>provided</scope>n</dependency>

可能有的人知道 optional 與 provided 的作用，他們很快會說出這樣是為了簡化依賴，避免引入不必要的依賴項?？墒嵌哂惺裁磪^別呢？本文就針對這個問題簡單的回答下。

optional

關于 optional，最常見的例子就是數據庫驅動。例如我們想做一個數據庫組件，而且這個數據庫組件需要支持多個數據庫的話，例如 MySQL、PostgreSQL、Oracle，那么組件端編寫的時候將各個數據庫的驅動全部引入，像下面這樣：

<!-- mysql -->n<dependency>n <groupId>mysql</groupId>n <artifactId>mysql-connector-java</artifactId>n</dependency>nn<!-- oracle -->n<dependency>n <groupId>com.oracle</groupId>n <artifactId>ojdbc14</artifactId>n</dependency>nn<!-- PostgreSQL -->n<dependency>n <groupId>org.postgresql</groupId>n <artifactId>postgresql</artifactId>n</dependency>

這樣數據庫組件倒是可以正常開發了，但是這樣做的話，構建出的數據庫組件，就同時包含了 mysql、oracle、postgresql 三種數據庫的驅動包。應用服務引入了我們的數據庫組件后，由于依賴傳遞，就也會同時引入了上面三種數據庫驅動包，加大了應用服務打包后的體積，也浪費了資源，甚至可能出現依賴沖突、jar 包沖突的問題。

optional 就是為了解決上述問題。回到上面的場景，分析后發現，實際上的應用服務不太可能同時使用三種不同的數據庫，它只需要自己用到的數據庫的驅動包就可以了。比如一個使用了 mysql 的服務，是沒有必要引入 oracle 的驅動包的。這時候 optional 就派上用處了。optional 表示該依賴是可選的，意味著構建后，標記為 optional 的依賴是不會被一起打入 jar 包的，也不會發生依賴傳遞。這樣不僅我們自己的組件端體積變小了，應用服務也解決了引入過多無用依賴的問題。

<!-- mysql -->n<dependency>n <groupId>mysql</groupId>n <artifactId>mysql-connector-java</artifactId>n <optional>true</optional>n</dependency>nn<!-- oracle -->n<dependency>n <groupId>com.oracle</groupId>n <artifactId>ojdbc14</artifactId>n <optional>true</optional>n</dependency>nn<!-- PostgreSQL -->n<dependency>n <groupId>org.postgresql</groupId>n <artifactId>postgresql</artifactId>n <optional>true</optional>n</dependency>

按照上面的方式將各個依賴設置為 optional 后，我們打包構建的 jar 將不再包含以上三種數據庫的驅動，這樣其他應用服務引入了我們的組件后，就不會默認帶上上面的數據庫驅動包。

可能有同學會疑慮，如果依賴沒有帶入，那么程序運行期間，會不會發生類找不到的問題？確實是這樣的，實際上 optional 表示可選，它將選擇權交給了上層應用服務。假如我的服務使用了 mysql，那么我就在服務自己的 pom.xml 中引入 mysql 的驅動包；如果用的是 oracle，同理也是自己引入 oracle 的驅動包，也就是按需使用。如果服務沒有引入任何數據庫驅動，那么最壞的情況應該是不會使用數據庫相關的功能，而不是報錯。

其實我理解這里 optional 更是一種規范，規范了以下行為：

1. optional 通常用于組件端應用，即一個 jar 包，而不是一個應用服務；
2. optional 的依賴不會一起被打包，不會經過依賴傳遞而引入上層應用服務中；
3. optional 的依賴，表示可選，及時沒有該依賴，也不影響程序運行，這里需要程序進行一些額外的判斷邏輯；
4. optional 的依賴，由上層應用服務來選擇是否引入。

舉個大白話的例子，去面館吃面，那么面館肯定不會把各種調料都放滿，而是將選擇權交給顧客，顧客按照自己的口味來添加調味料，加不加、加什么，都是顧客自己選。

provided

provided 其實與 optional 非常像，因為從結果來看，二者基本上沒有什么區別：標記為 provided 的依賴，和 optional 其實效果是一樣的，都不會被直接的打入包中，不會通過依賴傳遞而傳遞到上層應用服務的依賴中。那么為什么這里需要把 provided 與 optional 區分開呢？

這里其實，二者雖然在效果上沒有直接的區別，但是二者的使用場景不一樣。上面說了 optional 主要用于“可選依賴”的場景，依賴是否引入，都不會影響服務正常運行。而 provided 表示的不是依賴可選，它表示這個依賴是必須的，但是這個依賴通常是已經提供的，應用服務不需要額外引入，通常也不用關心。例如很多人使用 tomcat 作為服務運行容器，tomcat 自己會提供一些必備的依賴項，這些依賴項對于服務正常運行必須的，但是對于應用服務來說，這些依賴項是已經提供好的，不需要自己關心。

所以很多時候，會有人將 optional 與 provided 弄混，甚至一起使用，而且通常情況下是沒有什么問題的。不過我們還是需要明白二者的區別。雖然二者的行為是一致的，但是對于二者規定的規范確實不同的：

• optional 表示某個依賴可選，該依賴是否使用都不會影響服務運行。例子：吃面時候，醬油就是可選的，加不加都不會影響面的正常使用。
• provided 表示某個依賴必須，不過該依賴通常是由系統或者容器提供，不需要自己關系。例子：吃面時候，筷子、碗這樣的東西都是必須的，不過這些一般是店家給顧客備好，不需要顧客自帶。