Composer 文件提供了兩個基本的範例。我將嘗試解釋：列出被該軟體包替換的軟體包。這樣，你就可以 fork 一個包，並使用自己的版本號以不同的名稱發布，而需要原始包的軟體包可以繼續使用你的 fork 包，因為它會替換原始包。
假設你的軟體使用
和original/libraryother/package
，它們本身也需要
。 現在你認為 original/library 需要整合新功能，但是維護人員不同意你的建議在他們的軟體包中實現。所以你決定以 better/library 的名稱衍生出該函式庫，並標記一個新發行版。
回到軟體。當然，它應該開始使用 better/library 套件，所以要用它來代替，但 other/package 仍然需要
- 程式碼重複！如何讓那個套件使用你的 better/library 來取代 original/library？而不需要對它進行 fork ，只需要修改 composer.json（你仍然與 original/library 相容，所以它應該可以工作了）？ 你需要增加replace 關鍵字在 composer.json ：<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">"replace": {
"original/library":"1.0.2"
}</pre><div class="contentsignin">登入後複製</div></div>現在Composer 知道，在解決「other/package」的依賴關係時，任何來自「better /library」的包包都跟「original/library」一樣好。
這對包含子套件的套件也很有用，例如，主 symfony/symfony 套件包含所有 Symfony 元件，這些元件也可以作為單獨的套件使用。如果您需要主包，它將自動滿足單個組件之一的要求，因為它將替換它們。
相同的規則，只是角度略有不同：對於需要某些功能的任何其他元件，引入框架的元件是一種不錯的方法。但是，如果你在軟體中需要完整的框架，而另一個庫又需要該框架的元件，則該框架的
replace聲明使Composer 不必兩次安裝該單一元件，因為它已經包含在完整的框架中。注意: 替換版本中的佔位符通常是不好的
#在我最初的回答中，我建議：
"replace": {
"original/library":"1.*"
}這帶來的後果是：Composer現在將把你的庫版本1.0.0 和原來庫的任何版本1.x 一樣好，即使他們在某一天修復了一些東西或添加了一些特性並發布了版本1.2.34 。這也意味著，如果某一天你的「other/package」得到更新，並且需要「original/library:^1.1」，你庫中的替換仍處於活動狀態，並聲明它可以替換任何版本
1*，，即使你不更新內部的任何內容-這樣做也無法完成，但是如果你不做任何工作，你的舊代碼就永遠不會實現原始庫的新功能，但替換內容恰恰說明了這一點。
因此，從本質上：在替換版本中避免使用通配符版本！如果使用它們，則會對你無法了解或預測的未來做出聲明（除非你可以控制 original/library ，但即使這樣也要非常小心）。一定要使用你知道的並且可以完全重新實現的 original/library 。
原文網址：https://stackoverflow.com/questions/18882201/how-does-the-replace-property-work-with-composer#翻譯網址：https: //learnku.com/laravel/t/55200
以上是使用replace屬性來避免Composer的依賴衝突的詳細內容。更多資訊請關注PHP中文網其他相關文章！
