包你快速學會composer！

以下由composer教學專欄為大家介紹如何學會composer，希望對需要的朋友有幫助！

#當系統有不同的web應用，但需要共用很多程式碼怎麼辦
當系統需要一個擴充功能而這個擴充功能網上剛好有人提供了怎麼用
PHP程式碼如何升級，降級，回滾
如何分配任務，如何讓多個工程師一起進行開發任務

我在2011年接觸PHP，那時剛發布V5.3.5。從語言層面，我不認為PHP有過於明顯的缺陷，我們在有豐富面向web的函數庫的基礎上，還有了類別、SPL、匿名函數、etc。這些特性（一點都不「特」好）足以支撐一個大型專案的程式設計需求。

PHP5.3

可是，真當我們實際開發的時候，真的想用PHP寫程式的時候，卻常常會碰到一些抓狂的問題，這些問題和PHP倒是沒太多的關係。可是還是讓人很頭痛的。我們想寫一個網站的時候，我們可能會需要一個驗證碼，可是大部分的情況下，我不會自己想去寫驗證碼。網路上有那麼一大把的驗證碼類，我自然想直接用。可是當我想直接用，我要做的有：

1. 去搜尋引擎搜索，然後看每一個結果有沒有合適的程式碼，可以給我用。
2. 我找到了一個類，這時候我需要把這個類別引入我的項目，放在哪個目錄？怎麼autoload？它有沒有依賴什麼擴充？它會不會需要用在比我現在更高版的PHP上？這都是我要解決的問題。
3. 如果我要解決2說的所有問題，那我為什麼不直接寫一個？
4. 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就做了這樣的事：訂定標準。他所製定的標準有：

1. 編碼規格(psr-1 psr-2)
2. 自動載入規格( psr-4)
3. 一些通用介面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 mode\entity;class B{}#file demo.php$a = new \model\A();$b = new \model\entity\B();

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我们可以将业务逻辑、通用函数、逻辑拆分成不同的包，再也不需要做拷贝代码的蠢事了。

以上是包你快速學會composer！的詳細內容。更多資訊請關注PHP中文網其他相關文章！