Composer
Composer是PHP的依賴管理工具。它允許您聲明您的項目所依賴的庫, 并且它將為您管理 (安裝/更新) 它們。它以每個項目為基礎管理它們, 并將它們安裝在項目內的目錄 (如 vendor) 中. 默認情況下, 它不會在全局范圍內安裝任何內容。因此, 它是一個依賴關系管理器。
1. composer安裝
下載composer.phar文件，即可在任意操作系統上通過PHP運行軟件包工具，更新時可直接重新下載文件；
https://docs.phpcomposer.com/，中文文檔。修改環境變量后要重啟軟件、重啟CMD才會重新加載
下載地址
http://composer.p2hp.com/download
2. 修改composer倉庫鏡像地址
2.1 全局配置
# 修改鏡像地址
$ php composer.phar config -g repo.packagist composer https://packagist.phpcomposer.com
# 重置鏡像地址
$ composer config -g --unset repos.packagist
2.2 單個項目配置
在項目目錄下的composer.json文件內加入以下配置信息
"repositories": {
"packagist": {
"type": "composer",
"url": "https://packagist.phpcomposer.com"
}
}
3. composer命令
comoesr 的require/update都可以更新指定的依賴包（升級/降級）。
- require更為靈活些，未安裝則進行安裝，已安裝則根據傳入的版本號進行升級或降級。
- update則無法在命令行傳入指定的版本號，需要先手動編輯composer.json，指定新的版本號，然后執行更新命令。
- install可以用于項目初始化后，初次安裝依賴，且會優先讀取composer.lock中的版本號，以盡可能的保證協作開發中包版本的一致性。
composer list：獲取幫助信息；
composer init：以交互方式填寫composer.json文件信息
composer install：從當前目錄讀取composer.json文件，處理依賴關系，并安裝到vendor目錄下；
composer update：獲取依賴的最新版本，升級composer.lock文件；
composer require：添加新的依賴包到composer.json文件中并執行更新；
composer remove twbs/bootstrap; 卸載依賴包
composer search：搜索依賴包；
composer show：列舉所有可用的資源包；
composer validate：檢測composer.json文件是否有效；
composer self-update：將composer工具更新到最新版本；
composer self-update -r ：回滾到安裝的上一個版本
composer diagnose：執行診斷命令
composer clear：清除緩存
create-project：基于composer創建一個新的項目；
composer dump-autoload：在添加新的類和目錄映射是更新autoloader
composer.lock中存有的包版本記錄相當于執行 composer require packageName:versionNo，不存有的相當于執行composer update packageName with versionRule in composer.json。
當我們協同開發時，A 在本地安裝了新的依賴包，或者更新了依賴包，會寫入 composer.lock/composer.json,A 上傳至倉庫，B 拉取至本地后，應執行一次 composer install來同步團隊的版本變更。
提示
注意：每次更新完composer.json后，必須執行composer update后才會生效。
4. aotuload加載優化
composer autoload 慢的主要原因在于來自對 PSR-0 和 PSR-4 的支持，加載器得到一個類名時需要到文件系統里查找對應的類文件位置，這導致了很大的性能損耗，當然這在我們開發時還是有用的，這樣我們添加的新的類文件就能即時生效。 但是在生產模式下，我們想要最快的找到這些類文件，并加載他們。
composer dump-autoload -o （-o 等同于 --optimize）
這個命令的本質是將 PSR-4/PSR-0 的規則轉化為了 classmap 的規則， 因為 classmap 中包含了所有類名與類文件路徑的對應關系，所以加載器不再需要到文件系統中查找文件了。可以從 classmap 中直接找到類文件的路徑。
這個命令并沒有考慮到當在 classmap 中找不到目標類時的情況，當加載器找不到目標類時，仍舊會根據PSR-4/PSR-0 的規則去文件系統中查找；
composer dump-autoload -a （-a 等同于 --classmap-authoritative）
執行這個命令隱含的也執行了 Level-1 的命令， 即同樣也是生成了 classmap，區別在于當加載器在 classmap 中找不到目標類時，不會再去文件系統中查找（即隱含的認為 classmap 中就是所有合法的類，不會有其他的類了，除非法調用）；如果項目在運行時會生成類，使用這個優化策略會找不到這些新生成的類。
composer dump-autoload --apcu
apcu 可以理解為一塊內存，并且可以在多進程中共享。
這種策略是為了在 Level-1 中 classmap 中找不到目標類時，將在文件系統中找到的結果存儲到共享內存中， 當下次再查找時就可以從內存中直接返回，不用再去文件系統中再次查找。
在生產環境下，這個策略一般也會與 Level-1 一起使用， 執行composer dump-autoload -o --apcu, 這樣，即使生產環境下生成了新的類，只需要文件系統中查找一次即可被緩存 ， 彌補了Level-2/A 的缺陷。
要根據自己項目的實際情況來選擇策略，如果你的項目在運行時不會生成類文件并且需要 composer 的 autoload 去加載，那么使用 Level-2/A 即可，否則使用 Level-1 及 Level-2/B是比較好的選擇。
- Level-2的優化基本都是 Level-1 優化的補充，Level-2/A 主要是決定在 classmap 中找不到目標類時是否繼續找下去的問題，Level-2/B
- 主要是在提供了一個緩存機制，將在 classmap 中找不到時，將從文件系統中找到的文件路徑緩存起來，加速后續查找的速度。
- 在執行了 Level-2/A 時，表示在 classmap 中找不到不會繼續找，此時 Level-2/B 是不會生效的。
- 不論那種情況都建議要開啟 opcache， 這會極大的提高類的加載速度，性能提升至少 10倍。
- 提示
- php5.5 以后的版本中默認自帶了 opcache ，開啟opcache , 這樣會極大的加速類的加載。
- 參考資料：
- https://blog.csdn.net/zhouyuqi1/article/details/81098650
5. composer.json詳解
- name，必選屬性，表示包的名稱，由作者名稱和項目名稱組成，使用 / 分割，包名稱可以包含任何字符，包括空格，并且不區分大小
- description，必選屬性，表示包的簡短描述，通常這是一行介紹就行。
- version，非必選屬性，表示包的版本，版本的格式必須遵循 X.Y.Z 或 vX.Y.Z，可選后綴 -dev, -patch ( -p ), -alpha ( -a ), -beta ( -b ) 或 -RC， patch, alpha , beta 和 RC 后綴也可以跟一個數字。
- type，非必須屬性，表示包的類型，默認為庫 library，Composer 原生支持以下4種類型：
library: 默認類型，它只需要將文件復制到 vendor 目錄。project: 當前包是一個項目，而不是一個庫。例如Yii框架中的composer.json文件的type值就是project；metapackage: 包含需求并將觸發其安裝的空包，但不包含文件，并且不會向系統寫入任何內容。因此這種安裝類型并不需要一個 dist 或 source。composer-plugin: 一個安裝類型為 composer-plugin 的包，它有一個自定義安裝類型，可以為其它包提供一個 installler，我們也可以定義一個自定義類型。 - keywords，非必須屬性，表示一組用于搜索與篩選的與包相關的關鍵字
- homepage，非必須屬性，表示項目網站的 URL 地址
- readme，非必須屬性，表示README 文檔的絕對路徑
- time，非必須屬性，表示包的版本發布時間，必須是 YYYY-MM-DD 或者 YYYY-MM-DD HH:MM:SS 格式
- license，表示包的許可證，可以是一個字符串或者是一個字符串數組
- authors，非必須屬性，表示包的作者，這是一個對象數組。
- support，非必須屬性，表示獲取對項目支持的信息對象。
- require，必選屬性，表示必須安裝的依賴包列表，這些包必須滿足條件，否則不會安裝
- require-dev，非必選屬性，表示開發或運行測試時的依賴包列表。
- autoload，表示PHP 自動加載的映射，支持 PSR-4 和 PSR-0 自動加載，class 映射 和 files 引用。推薦使用 PSR-4 規范（添加類時，無需重新生成自動加載映射）
- repositories，非必選屬性，表示使用自定義的安裝源，Composer 默認只使用 packagist 的安裝源。通過定義 repositories 你可以從任何其他地方獲取包；
- config，非必選屬性，表示一組配置選項。
- scripts，非必選屬性，表示Composer 允許再安裝過程的各個部分中執行腳本。
- extra，非必選屬性，表示scripts 使用的任意擴展數據
4. composer自動加載的過程
- vendor/autoload.php 自動加載入口文件
- vendor/composer/autoload_real.php 自動加載核心文件
- vendor/composer/ClassLoader.php 自動加載類具體實現文件
- vendor/composer/autoload_static.php 所有的自動加載配置
- vendor/composer/autoload_classmap.php classmap自動加載配置
- vendor/composer/autoload_namespaces.php PSR0自動加載配置
- vendor/composer/autoload_psr4.php PSR4自動加載配置
- vendor/composer/autoload_files.php files自動加載配置
5.創建自己的composer包
composer init
創建并配置好自己包之后，到https://packagist.org/上傳即可。
prs-4規范
在PSR-4里邊需要定義一個命名空間前綴到路徑的映射（相對于包的根目錄），如果命名空間前綴Foo\指向一個文件目錄src/，當自動加載一個類時，比如Foo\Bar\Baz類，那么這個類的路徑為 src/Bar/Baz.php，命名空間前綴可以不在路徑之中。在composer.json中的命名空間必須以\結尾，以避免名字沖突
如果想要明確的指定，在每次請求時都要載入某些文件，那么你可以使用 files autoloading，通常作為函數庫的載入方式（而非類庫）。files引用的所有集合都會在install/update過程中生成，并存儲到vendor/composer/autoload_files.php文件中。
"autoload": {
"psr-4": {
"Nicen\\LocalImage\\": "src/"
},
"psr-0": {
"Tutsplus\\Library": "src"
},
"files": [
"src/auto.php"
]
},
每次修改composer.json之后，都需要update一次；（composer dump-autoload 命令可創建必要的自動加載器文件）
PSR-0 是 PHP-FIG 組推薦的自動加載標準。在 PSR-0 標準中，您必須使用命名空間來定義您的庫。完全限定的類名必須反映\\(\)*結構。此外，您的類必須保存在遵循與命名空間相同的目錄結構的文件中。
在 PSR-0 自動加載中，您需要將命名空間映射到目錄。在上面的例子中，我們告訴 Composer 任何以Tutsplus\Library命名空間開頭的東西都應該在src\Tutsplus\Library目錄中可用。
贈人玫瑰，手有余香
