下面由composer教程欄目給大家深入 composer autoload，希望對需要的朋友有所幫助！
這幾天看到 phphub 上面有人開始進坑怒看 laravel 源代碼，于是我也湊個熱鬧來看下這個故事。
眾所周知 composer 是現(xiàn)代 php 項目的基石， 與古老的 pear 不同， composer 并不是一款專注于系統(tǒng)級別 php 管理的包管理系統(tǒng)，而是基于項目的一個庫管理系統(tǒng)。這就好比 npm install -g 和 npm install 的區(qū)別。而且最主要的是 pear 不太能跟上時代的潮流，在大家都在用 psr-* 的時候 pear 依然我行我素自成一體。
好吧，可能這是好事，但是也是壞事。好事是很多優(yōu)秀的包都從 pear 發(fā)家致富，比如 php_codesniffer, php_unit 等等。但是隨著時代的發(fā)展，php社區(qū)也漸漸地從其他社區(qū)汲取到了一些精華，慢慢地向前發(fā)展。最近的 laravel 就是直接扔進了 composer。因為 psr-4 這個規(guī)范真是不能再爽更多。這真的是我用各種包用得最順手的一套命名規(guī)范了。
扯遠了，扯回 vendor/composer/autoload_real.php 這個核心 composer 文件。
自動加載的類型
總體來說 composer 提供了幾種自動加載類型
classmappsr-0psr-4files
這幾種自動加載都會用到，理論上來說，項目代碼用 psr-4 自動加載， helper 用 files 自動加載，development 相關(guān)用 classmap 自動加載。 psr-0 已經(jīng)被拋棄了，不過有些歷史遺留依然在用，所以偶爾也會看到。
classmap
這應該是最最簡單的 autoload 模式了。大概的意思就是這樣的：
{ "classmap": ["src/"]}然后 composer 在背后就會讀取這個文件夾中所有的文件 然后再 vendor/composer/autoload_classmap.php 中怒將所有的 class 的 namespace classname 生成成一個 key => value 的 php 數(shù)組
<?phpreturn [ 'app\\\\\\\\console\\\\\\\\kernel' => $basedir . '/app/console/kernel.php'];?>然后就可以光明正大地用 spl_autoload_register 這個函數(shù)來怒做自動加載了。
好吧 上面的例子其實有點 tricky 就是上面這個 autoload 實際上是根據(jù) prs-4 來生成出來的。不過這不重要，了解底層重要點，我們可以看到所有的所謂的 autoloading 其實可以理解為生成了這么一個 classmap，這是 composer dump-autoload -o 做的事兒。不然的話compoesr 會吭哧吭哧地去動態(tài)讀取 psr-4 和 prs-0 的內(nèi)容。
psr-0
現(xiàn)在這個標準已經(jīng)過時了。當初制定這個標準的時候主要是在 php 從 5.2 剛剛躍遷到 5.3 有了命名空間的概念。所以這個時候 psr-0 的標準主要考慮到了 <5.2 的 php 中 類似 acme_util_classname 這樣的寫法。
{ "name": "acme/util", "auto" : { "psr-0": { "acme\\\\\\\\util\\\\\\\\": "src/" } }}文檔結(jié)構(gòu)是這樣的
vendor/ acme/ util/ composer.json src/ acme/ util/ classname.phpclassname.php 中是這樣的
<?phpclass acme_util_classname{}?>我們可以看到由于舊版本的 php 沒有 namespace 所以必須通過 _ 將類區(qū)分開。
這樣稍微有點麻煩。指向一個文件夾之后 src 還要在 src 中分成好幾層文檔樹。這樣太深了。沒有辦法，但是似乎想要兼容 _ 的寫法仔細想想這是唯一的辦法了。（psr-0 要求 autoloading 的時候?qū)?類中的 _ 轉(zhuǎn)義為 '\\\\'）
所以在 php5.2 版本已經(jīng)徹底被拋棄的今天， fig 就怒推出了 psr-4
psr-4
這個標準出來的時候一片噴聲，大概的意思就是 fig 都是傻逼么，剛剛出了 psr-0 然后緊跟著進推翻了自己。不過 fig 也有自己的苦衷，幫沒有 namespace 支持的 php5.2 擦了那么久的屁股，在2014年10月21日的早晨，終于丟失了睡眠。
拋棄了 psr-0 的 composer 從此變得非常清爽。
最簡單來講就是可以把 prs-4 的 namespace 直接想想成 file structure
{ "name": "acme/util", "auto" : { "psr-4": { "acme\\\\\\\\util\\\\\\\\": "src/" } }}vendor/ acme/ util/ composer.json src/ classname.php可以看到將 acme\\\\util 指向了 src 之后 psr-4 就會默認所有的 src 下面的 class 都已經(jīng)有了 acme\\\\util 的 基本 namespace，而 psr-4 中不會將 _ 轉(zhuǎn)義成 \\\\ 所以就沒有必要有 psr-0 那么深得文檔結(jié)構(gòu)了。
<?phpnamespace acme\\\\util;class classname {}?>file
然而這還是不夠。因為可能會有一些全局的 helper function 的存在。
這個寫法很簡單就不多看了。
{ "files": [ "path/to/file.php" ]}autoload_real.php
好了看了所有的 autoload 類型那么直接怒看一發(fā)實現(xiàn)。
首先映入眼簾的就是一坨，我的是這樣的
composerautoloaderinit64c47026c93126586e44d036738c0862
為啥？
因為這個類是全局的啊少年。
作為模塊化大行其道的今天，全局的類總是有那么點奇怪。為了不讓這個 autoload 的 helper 污染全局，composer 的仁兄們還是絞盡腦汁怒弄了這么一個奇怪的 hash。這直接就逼迫廣大二筆程序員們不要跟這個撞衫。
好吧，接著往下看。
主要只有這么一個方法 getloader
<?php// autoload_real.php @generated by composerclass composerautoloaderinit64c47026c93126586e44d036738c0862{ private static $loader; public static function loadclassloader($class) { if ('composer\\\\autoload\\\\classloader' === $class) { require __dir__ . '/classloader.php'; } } public static function getloader() { if (null !== self::$loader) { return self::$loader; } spl_autoload_register(array('composerautoloaderinit64c47026c93126586e44d036738c0862', 'loadclassloader'), true, true); self::$loader = $loader = new \\\\composer\\\\autoload\\\\classloader(); spl_autoload_unregister(array('composerautoloaderinit64c47026c93126586e44d036738c0862', 'loadclassloader'));