接到乙個需求，需要展示乙個環狀圖和乙個柱狀圖，去pub上逛了一圈，選擇了功能比較全的mpflutterchart 庫。引入專案時，發現mpflutterchart 和國際化包flutter_localizations依賴不同的intl版本。為了能使用mpflutterchart 庫，嘗試了以下幾種解決衝突的方法。
網上查詢方法時，看到了這篇文章：以下方案一到方案三都是這篇文章了的。
在pub上檢視庫的歷史版本，往前嘗試，找到乙個不衝突的版本。方法太笨，不建議採用。
設定版本號為any，則as會自己查詢不衝突的版本，引入依賴。相當於機器幫做了手動嘗試的過程。如果能找到不衝突的版本，則可以使用方案三來優化。
方案二生效後，我們在pubspec.yaml裡面看不到使用的具體版本號。這是可以去pubspec.lock中檢視專案所依賴的具體版本，可把pubspec.yaml中的any替換成pubspec.lock的具體版本號。（該文章說是在pubspec.lock.yaml，不知是筆誤還是因為flutter版本與我的不一樣）。
以下是方案二無用情況下的處理
上面方案二很好，遺憾的是，對我的情況無用。我專案flutter_localizations依賴的intl是0.15.8，而mpflutterchart 依賴的是0.16.0；而且，mpflutterchart 是從第乙個版本就是依賴0.16.0的，即使設定為any，也找不到依賴0.15.8的版本號。
pub上找不到對應版本，那可以從github上clone**，修改依賴版本號後，通過本地引入的方式引入。
缺點：降低版本存在風險，那能不能給flutter_localizations公升級版本呢？想去pub上檢視flutter_localizations依賴的intl版本號，發現無法搜尋到。再看下pubspec.yaml檔案裡的引入方式，它和其他庫的引入明顯不同。1.下次公升級mpflutterchart 版本，需要重新colone**，修改依賴版本，不易維護
2.降低intl版本，可能會出現一些在0.16.0版本已被修復的問題，甚至有的新api調不到導致無法執行。
dependencies:
flutter:
sdk: flutter
#國際化支援
flutter_localizations:
sdk: flutter
缺點：單獨修改sdk的依賴版本可能會出現問題，但是整體公升級sdk則安全得多，因為每個sdk發布前必然經過大量的測試，尤其是穩定版的sdk。1.此修改只能改自己本地的**，如果別人拉取專案，而他電腦的依賴版本沒修改，依然無法執行，不易於團隊協作。
2.修改sdk包的依賴版本，可能會導致api不相容問題。
由於mpflutterchart 一開始就支援intl 0.16.0，因此猜測它發布的時候，flutter的sdk已經支援到0.16.0了。檢視了mpflutterchart 第乙個版本的發布時間，19年9月。檢視那段時間的flutter**，發現果然已經支援0.16.0。所以，如果flutter_公升級到1.12.13及以上的穩定版本，就不再有這個問題。
這個問題的原因是我的flutter_sdk版本過低，沒跟上官方最新版。但是如果以後還遇到其他第三方庫和sdk庫版本衝突，可以參考上面思路。
方法衝突 Gradle解決依賴版本衝突方法
在平時的gradle專案中，總會出現多專案依賴的版本衝突問題。下面簡單介紹依賴衝突的解決方法 使用exclude。指定group，module。其中module可以不指定。依賴hibernate，其中hibernate中依賴了org.slf4jcompile org.hibernate hibern...
Gradle解決依賴衝突
問題描述 有時候專案依賴的com.android.support support v4的版本會遇到和其他依賴庫中com.android.support support v4的版本發生衝突的情況。例如我專案中使用的22.2.1版本，但是引入的最新的fresco中依賴的是23的版本，由於fragment...
maven 傳遞依賴 衝突解決
依賴是會被傳遞 a c b a b c 這種依賴是基於compile這個範圍進行傳遞 在dependency配置中如果沒有寫scope預設就是compile範圍，依賴的傳遞主要是針對compile作用域 依賴的範圍 test範圍指的是測試範圍有效，在編譯和打包時都不會使用這個依賴 compile範圍...