下面由composer教程欄目給大家介紹如何學會composer，希望對需要的朋友有所幫助！
當系統有不同的web應用，但是需要共用很多代碼怎么辦
當系統需要一個擴展功能而這個擴展功能網上剛好有人提供了怎么用
PHP代碼如何升級，降級，回滾
如何分配任務，如何讓多個工程師一起進行開發任務
我在2011年接觸PHP，那時候剛發布V5.3.5。從語言層面，我不認為PHP有過于明顯的缺陷，我們在有豐富面向web的函數庫的基礎上，還有了類、SPL、匿名函數、etc。這些特性（一點都不“特”好吧）足夠支撐一個大型項目的編碼需求。
PHP5.3
可是，真當我們實際開發的時候，真的想用PHP寫代碼的時候，卻經常會碰到一些抓狂的問題，這些問題和PHP倒是沒太多的關系?？墒沁€是讓人很頭疼的。我們想寫一個網站的時候，我們可能會需要一個驗證碼，可是大部分的情況下，我不會自己想去寫一個驗證碼。網上有那么一大把的驗證碼類，我自然想直接用。可是當我想直接用，我要做的有：
- 去搜索引擎搜索，然后看每一個結果有沒有合適的代碼，可以給我用。
- 我找到了一個類，這時候我需要把這個類引入我的項目，放在哪個目錄？怎么autoload？它有沒有依賴什么擴展？它會不會需要使用在比我現在更高版本的PHP上？這都是我要解決的問題。
- 如果我要解決2說的所有問題，那么我為什么不直接寫一個？
- f**k it
就算用我自己的代碼，當我 有多個web應用（電腦端、wap端 、api接口很正常吧），我當然希望它們不在一個項目（目錄）里活稀泥，會增加我查看指定文件的難度，從而也增大我的維護成本。可是當我把這些web應用都分開以后，有那么多的通用的代碼（model、logic、auth。。。），這些代碼我應該如何處理，我修改了一個web應用的一個小邏輯，我還要去其他應用修改，要么我記不住，要么再小的一個改動也會變的讓人想砸電腦、辭職、出去散心。
好吧，我把這些代碼進行拆分，通過autoload來互相使用，這樣還可以讓更多的人參與開發，可線上的情況那么復雜，萬一有哪段代碼出問題了，萬一有哪個web應用比較特殊，新的代碼對它來說不適用。維護起來也是個問題，接手了這樣一個依賴于很多其他項目的web應用，也許稍微改一下代碼都會有很多麻煩，因為那些autoload的代碼也很難讓人有很直觀的知道這個web應用到底用了哪些其他項目的哪些代碼。
可是面對PHP，我又不想破罐子破摔啊，畢竟寫起來那么方便。我還不想脫坑。但是上述問題不解決，反正我個人認為寫PHP還是一件挺崩潰的事情。我們來看其他語言是怎么解決這個問題的。JAVA天然的包機制讓它可以用maven，node的npm，連比PHP還老的Perl都有cpan。難道PHP不應該有一個包管理機制嗎？
還好這些問題沒有陪伴我的PHP時光太久，因為很快，PHP有了Composer，天亮了。
Composer 是 PHP 的一個依賴管理工具。它允許你申明項目所依賴的代碼庫，它會在你的項目中為你安裝他們。
這是Composer中文官網自己的簡介。
我試圖從使用經驗上來闡述一下這句話。
它允許你申明項目所依賴的代碼庫 就是說當你想用什么代碼不再需要自己復制了，而是通過聲明的方式來告訴Composer就好了，就像去餐廳吃飯一樣，你不用教廚師怎么做，更不用自己做，也不用自己端盤子自己吃，而是告訴服務員，你要吃什么，告訴它就好了，當然，你不能告訴他我今天胃不舒服，給我做點方便消化清淡一點的菜，反正我從來不這么點菜，總得告訴他們你到底要吃什么菜，具體的菜名。這就是和之前在搜索引擎里找代碼的區別，你不能通過關鍵詞告訴Composer，而是要告訴它你要的代碼庫的名字，WTF？我哪里知道代碼的名字，誰也不可能知道別人代碼的名字，除非有個地方包含了所有的代碼而且提供了搜索的功能讓我們找到他們并知道他們的名字，
packagist.org就是干這個的。我們再也不用去各個搜索引擎里憑運氣找了，在這里搜索關鍵詞不會出現廣告，不會出現莆田也不會出現JD。
它會在你的項目中為你安裝他們: ?告訴了Composer以后，Composer自然會幫我們把菜端上來，這是一件任何人都可以理解的事情，我們想要的代碼不知道在哪臺服務器里放著，但是Composer會幫我們下載到本地。可是這里還有一個問題，下載下來以后怎么用，我們知道PHP里想用一個文件必須得include或require，Composer下載下來以后，這盤菜怎么吃，需要自己準備碗筷嗎？還好還好，還有一個好東西PHP-FIG,這個玩意它不生產代碼，不提供任何實際問題的解決方案。他唯一做的事情就是BB， ?那他BB一些什么呢？就像我上面說的那樣，因為一些基礎工具（比如Composer）的缺失，PHP開發很難有一些標準，比如編碼規范，比如目錄結構，比如如何自動加載類，比如如何打log，比如如何使用緩存，這樣就會導致什么呢？不同的公司、不同的PHP程序員就會開始八仙過海各顯神通，當然這對開發來講短時間到也沒什么，可是長久來看，這是會增加開發成本、維護成本的，當我們換一家公司、接手一個項目我們要從頭開始理解代碼，甚至在一個團隊里我們都會因為沒有標準而增加溝通成本。所以PHP-FIG就做了這樣的事：制定標準。他制定的標準有：
- 編碼規范 (psr-1 psr-2)
- 自動加載規范(psr-4)
- 一些通用接口 log(psr-3) cache(psr-6) http(psr-7)
這些標準在官網上都有詳細的描述。我們這里要討論的是psr-4。我在這里按照我自己的理解和使用經驗稍微闡述一下：psr-4的自動加載基于文件夾和命名空間，我們需要指明一個根目錄對應一個根命名空間，在這個基礎上，我們可以通過除去根命名空間以外的命名空間和類名來在根文件夾下找到這個PHP文件并加載
#根文件夾 lib#根命名空間 model#file lib/A.phpnamespace model;class A {}#file lib/entity/B.phpnamespace modeentity;class B{}#file demo.php$a = new modelA();$b = new modelentityB();
Composer就實現了可以根據指明標準（如psr-4）和映射關系(如代碼中的lib->model)來生成自動加載類的功能。事實上Composer提供了這些標準：
files ?指明PHP文件路徑的方式，這種方式會在每次請求時都要載入這些文件，適合一些通用函數的PHP文件
Classmap 比files智能一些，可以指明一個文件夾或一個文件來進行自動加載，缺點是即使是指明了一個文件夾，這個文件夾下增加了一個文件都需要Composer重新生成一次autoload文件，適合一些不能使用psr-4的類或類庫，比如一個第三方接口的client，這個client可能在psr-4規則出現之前就有了，那么我們還是希望用Composer進行管理就可以使用這種方式
psr-0 psr-4的前身，以前落伍了，就當我沒說過
psr-4 就像我上面介紹的，這種方式增加一個或多個文件也不需要重新生成autoload文件，因為它是按照命名空間和文件夾的映射關系來加載的。
那么Composer實現了這個有什么好處呢？
我們自己不需要寫什么autoload文件了，同時這個標準也很好理解接受，維護和學習代碼的成本也降低了
只要我們需要的第三方庫也是使用Composer來處理自動加載的，我們只需要require這個包，那么加載這個第三方庫的代碼Composer也會處理，我們有了一個超強的autoload文件
所以，我們要做的就是學習和Composer打交道然后開始享受全球開發者的代碼了。
就像上面描述的,Composer就像一個機器貓，你要什么它就給什么，那么交互的方式就類似于SQL語句那樣，告訴它你要什么然后它給你結果。所以我們要做的就是描述需求，也就是當產品經理，好過癮。
{ "name": "fmw/test", "description": "fmw test", "authors": [ { "name": "zzc", "email": "2272713550@qq.com" } ], "repositories": [ { "type": "composer", "url": "http://package.fmw.com" } ], "version":"1.0.106", "require": { "fmw/other-layer":"1.*", "fmw/common":"1.*" }, "require-dev":{ "php-console/php-console": "^3.1", "phpdocumentor/phpdocumentor": "2.*" }, "autoload":{ "psr-4":{ "model":"src/" } } }
以上代碼是一個我用過的composer配置文件，可以看出這是一個標準的json。我們來看一下這段json的每個key：
name和description是你給這個php項目起的名字，當這個項目僅僅是一個web項目，這兩個其實不是很重要，但是這個項目其實是一個向外發布的代碼庫，就很關鍵了，name需要獨一無二，description需要一句話來描述這個包的作用。
authors就是相當于宣布一下主權，可以有多個
repositories相當于你需要下載的代碼庫所在的倉庫，默認會有一個全局的倉庫，具體是什么就不在這里說了，上面的某個網址有介紹，在這里添加一個是因為如果你有個私人的倉庫（有些代碼不太適合放在公開的倉庫吧），則可以在這里聲明
version是版本號，這個是跨時代的功能啊，有了這個，PHP程序員也可以刷版本號了??！
require則是上面闡述了很多的功能，解決了我說的那些痛點，通過“name”:”version”聲明，可以有多個，require以后使用composer install命令composer會下載代碼并自動加載
require-dev用法一致，但是功能不同，是用來聲明一些在開發時候才用到的包，比如測試、文檔等等
autoload 上面有介紹，就不廢話
上面工作做完以后，執行composer install我們可以看到和composer.json同級的文件夾下生成了一個vendor文件夾，我們新建一個php文件引入vendor下的autoload.php文件就可以使用包和我們自己聲明的autoload的php文件了
#index.php
include ‘./vendor/autoload.php’;
到這里，我們就算會用了composer，至于如何使用composer的功能就不拾人牙慧了，但是還有一些問題想討論一下。
比如有些代碼不太適合放在公開的倉庫，但是我們還是希望包的形式來使用，畢竟這樣的話，一個公司內部就很容易分工了，每一個PHP程序員維護若干個包，多方便，所以建立一個內部的代碼倉庫是很重要的。這時候Composer官方提供的工具satis就可以發揮作用了。
Simple static Composer repository generator
這是它的介紹，一個簡單的Composer倉庫生成器。使用它的步驟如下：
在合適的目錄執行 php composer.phar create-project composer/satis –stability=dev –keep-vcs(前提是你已經按照Composer)
新建一個satis.json 實例如下
{ "name": "My Repository", "homepage": "http://packages.dev.com", "repositories": [ {"type": "vcs", "url": "http://git.dev.com/maxincai/package1.git"}, {"type": "vcs", "url": "http://git.dev.com/maxincai/package1.git"}, ], "require": { "maxincai/package1": "*", "maxincai/package2": "*", } }
執行 php bin/satis build satis.json public/(public就是所有包的存放目錄)
將public目錄作為一個web服務對外發布就好了
使用的時候只需要在repositories多加一項（就像我在上面的composer.json做的那樣），然后引入包就好了
關于Composer，上面就是我目前要說的了，通過Composer我們可以將業務邏輯、通用函數、邏輯拆分成不同的包，再也不需要做拷貝代碼的蠢事了。
