轉(zhuǎn)帖：http://www.yanbin.org/2006/12/07/welcome_to_php_5_2/經(jīng)過(guò) N 次的跳票和等待，PHP 5.2已于 11 月2 日正式發(fā)布。根據(jù) PHP 小組不成文的開(kāi)發(fā)習(xí)慣，PHP 5.0 系列更大程度上像一個(gè)技術(shù)展示版，性能低下（甚至還不如 PHP4，這主要?dú)w結(jié)與Zend中重寫(xiě)的更加強(qiáng)大也更加復(fù)雜的OO機(jī)制），穩(wěn)定性也有所欠缺，目前 PHP 開(kāi)發(fā)組已經(jīng)放棄了對(duì)這個(gè)系列的開(kāi)發(fā)。PHP 5.1 系列則側(cè)重于對(duì)性能的改善，和 PHP 5.0 系列已經(jīng)不可同日而語(yǔ)。但隨著 PHP5.2系列的發(fā)布，PHP5.1也已經(jīng)和 PHP4.4系列一樣進(jìn)入了維護(hù)狀態(tài)，除非出現(xiàn)重大的BUG和安全隱患否則將不再更新。新發(fā)布的 PHP 5.2 除了修復(fù)了以往200多個(gè)BUG以外，它還將性能進(jìn)一步提高，尤其是改善了在高負(fù)載情況下的表現(xiàn)，而且在安全性的處理上也做出了很大的改進(jìn)。同時(shí)也增加了很多很實(shí)用的技術(shù)（比如 JSON、Zip等支持），另外還有一些原本定為 PHP6 的特性也已經(jīng)被提前實(shí)現(xiàn)在這個(gè)版本當(dāng)中。可以說(shuō)，相對(duì)于最初的 PHP5 版本，這次的改變幾乎是半革命性的（革命性這個(gè)形容詞當(dāng)然是留給 PHP6 的J）。下面我自己掌握的一些信息和理解，嘗試向大家介紹一下 PHP 5.2的新特性，如有不當(dāng)之處，還望方家斧正：1、最明顯的當(dāng)屬 PHP 5.2 在移除了filepro 和 hwapi 兩個(gè)擴(kuò)展（這兩個(gè)被移動(dòng)到了 PECL）的同時(shí)另外增加了4個(gè)新的擴(kuò)展：Date、JOSN、Filter和ZIP。;

其實(shí)從 PHP 5.1 開(kāi)始，在 PHP 核心增加了一個(gè) Date 擴(kuò)展，重寫(xiě)了對(duì)日期/時(shí)間（主要是時(shí)區(qū)方面）的支持。所不同的是，PHP 5.2 更進(jìn)一步，日期和時(shí)區(qū)則分別成為了類(lèi) DateTime 和 DateTimeZone 的一個(gè)對(duì)象。大家可以在 PHP CLI 中運(yùn)行php –rc DateTime 或 php –rc DateTimeZone 來(lái)看一下這兩個(gè)類(lèi)的詳細(xì)信息。需要注意的是如果你的程序中已經(jīng)存在有名為DateTime 或 DateTimeZone 類(lèi)的話，那想在 PHP 5.2 中運(yùn)行就必須改名了。(著名的開(kāi)源 CRM ：vtigercrm 已經(jīng)有了前車(chē)之鑒); JSON 擴(kuò)展實(shí)現(xiàn)了則實(shí)現(xiàn)對(duì) JavaScript Object Notation (JSON) 這種輕量級(jí)數(shù)據(jù)交換格式的支持。在 PHP 5.2 中這個(gè)擴(kuò)展是默認(rèn)被啟用的。相信很多開(kāi)發(fā)人員都為 PHP與 JavaScript 之間的通信發(fā)愁過(guò)，尤其是現(xiàn)在這個(gè)流行 Ajax 的時(shí)代。而現(xiàn)在，我們用JSON 就可以很輕易的解決這個(gè)問(wèn)題。JSON數(shù)據(jù)能夠直接為服務(wù)器端代碼使用, 并且也能夠讓客戶端的 JavaScript簡(jiǎn)單地通過(guò) eval() 來(lái)進(jìn)行讀取，這就大大簡(jiǎn)化了服務(wù)器端和客戶端的代碼開(kāi)發(fā)量。雖然以前在 PHP 里面也有一些 JSON 類(lèi)來(lái)支持，但這哪有 PHP 的原生支持來(lái)得高效和快捷呢？ Filter 擴(kuò)展負(fù)責(zé)校驗(yàn)和過(guò)濾數(shù)據(jù)，這個(gè)擴(kuò)展主要是為了處理像用戶的輸入那樣的不可靠數(shù)據(jù)而設(shè)計(jì)的。這個(gè)擴(kuò)展也是默認(rèn)被啟用的。默認(rèn)情況下的RAW 模式將不會(huì)以任何方式影響輸入的數(shù)據(jù)，也就是說(shuō)這不會(huì)對(duì)現(xiàn)有代碼產(chǎn)生任何影響。但我們?cè)谝院蟮拈_(kāi)發(fā)中應(yīng)該盡可能地利用這個(gè)擴(kuò)展來(lái)進(jìn)行敏感字符的過(guò)濾，因?yàn)檫@不但簡(jiǎn)化了一些表單的驗(yàn)證工作，而且提高了程序的安全性和運(yùn)行效率。 ZIP 擴(kuò)展將允許我們對(duì) Zip 壓縮包及其包內(nèi)的文件進(jìn)行讀寫(xiě)操作。也就是說(shuō)，我們對(duì) Zip文件不僅能看，而且還能摸：它提供了對(duì) Zip 文件的完全支持。這項(xiàng)特性的應(yīng)用是非常廣泛的，具體帶來(lái)的種種好處我就不再多說(shuō)了。;

當(dāng)然，關(guān)于這些擴(kuò)展的具體細(xì)節(jié)還得查閱我們無(wú)所不能的 PHP 手冊(cè)。:D2、改進(jìn)了內(nèi)存管理器，使之在高負(fù)載情況下具有更佳的表現(xiàn)。 按照 “Zend 二老”之一也就是 “Zend”中那個(gè)“nd”的說(shuō)法，這個(gè)新的內(nèi)存管理器是分層（hierarchical）的。這個(gè)管理器共有三層：存儲(chǔ)層（storage）、堆（heap）層和emalloc/efree層。存儲(chǔ)層通過(guò)malloc()、mmap()等函數(shù)向系統(tǒng)真正的申請(qǐng)內(nèi)存，并通過(guò) free() 函數(shù)釋放所申請(qǐng)的內(nèi)存。存儲(chǔ)層相當(dāng)于Zend 自己的“內(nèi)存?zhèn)}庫(kù)”，通常申請(qǐng)的內(nèi)存塊都比較大。堆層（注意這里的堆并不是指操作系統(tǒng)所管理的堆，而是 Zend 內(nèi)存管理器的所管理的內(nèi)存堆）就把它們從存儲(chǔ)層要過(guò)來(lái)并分割成一些較小的塊。而 emalloc/efree層就是指通過(guò) PHP API的emalloc()/efree() 函數(shù)所申請(qǐng)和釋放的內(nèi)存。emalloc() 并不直接同存儲(chǔ)層打交道，同它們接頭的是堆層。負(fù)責(zé)把比原來(lái)的管理器在同等條件下會(huì)分配更小的內(nèi)存，但速度更快。它首先會(huì)從系統(tǒng)（堆）中申請(qǐng)一些較大的內(nèi)存塊，然后自己來(lái)管理這個(gè)堆。php.ini 中的memory_limit 值雖然還會(huì)被檢用，但已不再是每次emalloc() 調(diào)用時(shí)都檢用，而僅僅是在向系統(tǒng)申請(qǐng)那些大的內(nèi)存塊時(shí)被檢用。熟悉一些服務(wù)器端編程的朋友可能會(huì)馬上想到一個(gè)詞：內(nèi)存池！沒(méi)錯(cuò)，這基本上就是一個(gè)內(nèi)存池。至少我是這么認(rèn)為的。:D

內(nèi)存池技術(shù)其實(shí)這是服務(wù)端編程中很常見(jiàn)。使用內(nèi)存池技術(shù)可以有效地避免頻繁的內(nèi)存申請(qǐng)/釋放操作，在內(nèi)存池技術(shù)中，內(nèi)存釋放時(shí)實(shí)際上并沒(méi)有通知操作系統(tǒng)真實(shí)的釋放和回收，而僅僅是對(duì)將要釋放的內(nèi)存做個(gè)了標(biāo)記，表示該部分內(nèi)存已經(jīng)不再使用。等下一次申請(qǐng)內(nèi)存時(shí)，就從這些“可用”的內(nèi)存鏈表中取出一個(gè)內(nèi)存塊，從而避免了頻繁的內(nèi)存申請(qǐng)/釋放操作，大大節(jié)省了系統(tǒng)資源。根據(jù)測(cè)試和統(tǒng)計(jì)，在 PHP 4.4版本中，一個(gè)典型的較為簡(jiǎn)單的請(qǐng)求就有超過(guò) 20,000次的對(duì)系統(tǒng)堆的申請(qǐng)和釋放操作，這花費(fèi)的時(shí)間相當(dāng)于整個(gè)腳本所花費(fèi)時(shí)間的 20% 左右。由此可見(jiàn)，若能降低這種資源消耗則效果是極為可觀的。與此同時(shí)，采用內(nèi)存池技術(shù)也帶來(lái)一個(gè)更為重要的“副作用”：避免了大量的“內(nèi)存碎片”。一般情況下，內(nèi)存碎片是對(duì)系統(tǒng)沒(méi)有多大影響的，但服務(wù)端應(yīng)用明顯不同于一般應(yīng)用，服務(wù)端會(huì)面臨很高數(shù)量級(jí)的訪問(wèn)請(qǐng)求，這些請(qǐng)求也伴隨著更高數(shù)量級(jí)的內(nèi)存申請(qǐng)/釋放操作。內(nèi)存碎片過(guò)多將導(dǎo)致內(nèi)存利用率降低，降低內(nèi)存分配速度，嚴(yán)重時(shí)還會(huì)觸發(fā)內(nèi)存分配失敗，盡管此時(shí)理論上仍有可分配的物理內(nèi)存。最后，內(nèi)存池技術(shù)還有一個(gè)不太引人注意的好處：它能降低內(nèi)存泄漏的概率。因?yàn)閷?shí)際申請(qǐng)的內(nèi)存塊雖然尺寸較大，但數(shù)量較少，而且一般情況下都是統(tǒng)一申請(qǐng)，實(shí)際釋放時(shí)也可以統(tǒng)一釋放。顯然，這比代碼中即時(shí)申請(qǐng)，而沒(méi)有即時(shí)釋放所造成內(nèi)存泄漏的概率要小很多。;

不過(guò)采用內(nèi)存池技術(shù)的管理器也明顯要比常規(guī)管理器（指的是內(nèi)存即時(shí)申請(qǐng)，即時(shí)釋放的管理機(jī)制）的內(nèi)存開(kāi)銷(xiāo)要大，因?yàn)槌苏嬲暾?qǐng)的內(nèi)存外，管理器還得負(fù)責(zé)維護(hù)每個(gè)內(nèi)存塊的狀態(tài)，因此 PHP 5.2 中把 php.ini中 memory_limit 指令值從默認(rèn)的 8M 提升為 16M 。這看似增加了內(nèi)存消耗，并且也需要極少量的CPU資源來(lái)管理，但由于內(nèi)存碎片的減少實(shí)際上并沒(méi)有增加多少消耗，再結(jié)合其他方面的表現(xiàn)，可以說(shuō)是所得遠(yuǎn)大于所失，尤其是在高負(fù)載情況下。; 3、PHP 5.2 也對(duì) INI 指令的存取方面做了優(yōu)化。PHPer 都知道，在 PHP 腳本中我們可以用 ini_set() 函數(shù)動(dòng)態(tài)改變某個(gè) PHP 指令的值。但問(wèn)題是在請(qǐng)求結(jié)束后你還得把這些改變的值給恢復(fù)過(guò)來(lái)以保證下個(gè)腳本能正確使用。在 PHP 5.2 之前，PHP 的做法可謂是不辭勞苦，逐個(gè)遍歷 INI 指令并恢復(fù)的。如果你是整個(gè)腳本都是 ini_set() 也就罷了（當(dāng)然這個(gè)情況也是極其罕見(jiàn)的。：）），萬(wàn)一我的腳本中很少使用甚至根本就沒(méi)有使用這個(gè)函數(shù)那我不就是虧大了？因此 PHP 5.2 為了解決這個(gè)問(wèn)題又額外增加了一個(gè)表專(zhuān)門(mén)保存更改過(guò)的指令，這樣就不用來(lái)回挨個(gè)恢復(fù)了。4、PHP 5.2 還對(duì) require_once(); 和 include_once() 兩個(gè)函數(shù)進(jìn)行了優(yōu)化。

PHP 5.2 以前 require_once(); 和 include_once() 的做法是無(wú)論某個(gè)文件是否已經(jīng)被緩存或編譯過(guò)，統(tǒng)統(tǒng)是先 fopen() 再說(shuō)，打開(kāi)成功后在查詢一下是否已經(jīng)緩存過(guò)。這么處理的原因就是 在 PHP 5.1 以前沒(méi)有很完美的解決 realpath() 相對(duì)路徑和符號(hào)連接方面的問(wèn)題。因?yàn)槿舨荒芪ㄒ坏卣_地確定某個(gè)路徑的真實(shí)路徑表示那么你就無(wú)法利用這個(gè)路徑的唯一性去解決某個(gè)問(wèn)題。而 fopen 則沒(méi)有這個(gè)顧慮。realpath() 的這個(gè)問(wèn)題在 PHP 5.1 中被徹底搞定了，但還沒(méi)來(lái)得及應(yīng)用到 require_once(); 和 include_once() ，結(jié)果就拖遲到現(xiàn)在。解決這個(gè)問(wèn)題的好處是在于避免了 fopen 這個(gè) I/O 操作，在很多高負(fù)載情形中，通常都是 數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)或者磁盤(pán) I/O 而不是 CPU 成為瓶頸。5、對(duì)HashTable 的復(fù)制也進(jìn)行了優(yōu)化。HashTable在ZendEngine是一個(gè)很基本的數(shù)據(jù)結(jié)構(gòu)，數(shù)組本質(zhì)上就是一個(gè) HashTable。對(duì)HashTable 的優(yōu)化也將意味著對(duì)數(shù)組的復(fù)制操作（無(wú)論是顯式還是隱式）速度將會(huì)有一定的提升。;

6、其他的一些性能方面的改進(jìn)。PHP 5.2 也對(duì)在FastCGI SAPI 模塊中訪問(wèn)環(huán)境變量的性能做了少許優(yōu)化。以前則是逐行搜索，現(xiàn)在則是通過(guò) Hash 值來(lái)存取。除此之外，PHP 5.2還對(duì)str_replace() 和 implode() 函數(shù)以及“try {} catch {}”塊等都做了一定的優(yōu)化。 下面是對(duì)一些語(yǔ)言特性和安全特性方面的改進(jìn)：

1、繼PHP 5.0增加了一個(gè) E_STRICT的錯(cuò)誤報(bào)告級(jí)別（常量值為 2048）之后，PHP 5.2 也新增了一個(gè)錯(cuò)誤報(bào)告級(jí)別：E_RECOVERABLE_ERROR ，其常量值為 4096 。這個(gè)級(jí)別的錯(cuò)誤主要是從E_ERROR中但可以被用戶自定義的錯(cuò)誤處理程序（一般通過(guò)set_error_handler() 函數(shù)指定）所捕捉的情況轉(zhuǎn)化而來(lái)。如果一個(gè)E_RECOVERABLE_ERROR 未被捕捉并處理，那么它的表現(xiàn)就和所有 PHP 版本中的E_ERROR一樣會(huì)導(dǎo)致程序中止。在錯(cuò)誤日志中，該類(lèi)型的錯(cuò)誤將被記錄成“可捕捉的致命錯(cuò)誤（Catchable fatal error）”。;

導(dǎo)致 PHP 拋出 E_RECOVERABLE_ERROR 的情況通常是指那些很危險(xiǎn)，但還不足以讓 Zend Engine 崩潰的情況。比方說(shuō)，有下面一段代碼： class foo {function bar(foo $a) { } }

$a = new foo ; $a->bar(new stdClass) ;很明顯，類(lèi) foo 的bar 函數(shù)要求一個(gè) foo 類(lèi)型的參數(shù)，但實(shí)際代碼中卻給了一個(gè) stdClass 類(lèi)型的參數(shù)。在PHP 5.2 以前，這會(huì)導(dǎo)致一個(gè) E_ERROR（Fatal error: Argument 1 passed to foo::bar() must be an instance of foo……）。但在 PHP 5.2（包括以后的 PHP6）則會(huì)導(dǎo)致一個(gè)E_RECOVERABLE_ERROR（Catchable fatal error: Argument 1 passed to foo::bar() must be an instance of foo……）。這種錯(cuò)誤是可以被捕捉的，如果你通過(guò)set_error_handler() 指定了一個(gè)錯(cuò)誤處理函數(shù)（即使是你在這個(gè)函數(shù)中沒(méi)有處理E_RECOVERABLE_ERROR），那么程序就會(huì)繼續(xù)運(yùn)行。但如果你沒(méi)有指定一個(gè)錯(cuò)誤處理函數(shù)，那么這個(gè) E_RECOVERABLE_ERROR 錯(cuò)誤就會(huì)和 E_ERROR 一樣，會(huì)立即導(dǎo)致程序中止。;

2、相應(yīng)的，錯(cuò)誤報(bào)告級(jí)別 E_ALL 也將會(huì)包含上述E_RECOVERABLE_ERROR。這也就意味著常量 E_ALL 的值將會(huì)從原來(lái)的2047 變?yōu)?6143。注意，在 PHP 5.0和 PHP 5.1中雖然增加了E_STRICT，但在這兩個(gè)版本中 E_ALL 并不包含E_STRICT。而在以后的版本（如 PHP5.2、PHP6等）中E_ALL 則包含了包括E_STRICT和E_RECOVERABLE_ERROR在內(nèi)的所有錯(cuò)誤級(jí)別。 在PHP 5.0/5.1 中我們想設(shè)置error_reporting為E_ALL就不得不采用error_reporting(E_ALL | E_STRICT) 的寫(xiě)法，感覺(jué)極為別扭，也很容易造成一些疏忽和誤導(dǎo)。在 PHP5.2當(dāng)中我們就沒(méi)有這個(gè)苦惱了。另外如果你在 Apache 的配置文件（如 httpd.conf）或 .htaccess 文件中用error_reporting 設(shè)置了錯(cuò)誤報(bào)告級(jí)別（比如：php_value error_reporting 4095），由于 Apache 不支持 PHP 常量 ，那你還得手工去適當(dāng)調(diào)整這些錯(cuò)誤報(bào)告級(jí)別的數(shù)值。 3、添加了allow_url_include 這個(gè) ini 指令來(lái)輔助 allow_url_fopen 操作；這個(gè)是 PHP 5.2 在安全方面的重大更新之一。使用這個(gè)指令可以讓我們區(qū)分開(kāi)對(duì)遠(yuǎn)程文件的標(biāo)準(zhǔn)文件操作和包含操作。我們通常需要進(jìn)行前面的標(biāo)準(zhǔn)操作，而后面的包含操作則通常是危險(xiǎn)的發(fā)源地。從 PHP 5.2 開(kāi)始，你的本地腳本可以在禁止遠(yuǎn)程包含操作的同時(shí)進(jìn)行標(biāo)準(zhǔn)遠(yuǎn)程文件操作。事實(shí)上，這個(gè)就是默認(rèn)配置。 PHP 5.2 把原來(lái)的allow_url_fopen 指令分成了allow_url_fopen 和allow_url_include 兩個(gè)指令。如果allow_url_fopen 操作是禁止的，那么allow_url_include 也將被禁止。默認(rèn)情況下將會(huì)允許進(jìn)行 allow_url_fopen 操作，但是禁止allow_url_include 。這樣就能非常有效的避免遠(yuǎn)程代碼注入（remote code injection）。這個(gè)本來(lái)也是打算在 PHP6中添加的，現(xiàn)在我們提前用到了。:D4、PHP 5.2 增加了對(duì)接口中構(gòu)造函數(shù)類(lèi)型(簽名) 強(qiáng)制性檢查的支持。 從 PHP 5.2 開(kāi)始，如果你在一個(gè)接口中聲明了一個(gè)構(gòu)造函數(shù)，那么在所有實(shí)現(xiàn)該接口的類(lèi)都必須包含一個(gè)構(gòu)造函數(shù)，并且這個(gè)構(gòu)造函數(shù)要與該接口的構(gòu)造函數(shù)的簽名完全一致。這里術(shù)語(yǔ)“簽名”的意思是函數(shù)的參數(shù)和返回值的類(lèi)型（包括其語(yǔ)言類(lèi)型以及是引用傳遞還是值傳遞），這個(gè)概念有點(diǎn)類(lèi)似于C 語(yǔ)言中 “原型”。看以下代碼：interface constr { function __construct() ;}

class implem implements constr { function __construct ($a) { }}這段代碼在 PHP5.0和 PHP 5.1 里面運(yùn)行是毫無(wú)問(wèn)題的，但在 PHP 5.2中則會(huì)拋出一個(gè)錯(cuò)誤：Fatal error: Declaration of implem::__construct() must be compatible with that of constr::__construct()，提示類(lèi)implem 的構(gòu)造函數(shù)與接口constr 的構(gòu)造函數(shù)的聲明不匹配。值得一提的是這項(xiàng)新特性的添加過(guò)程是很有意思。，有興趣的朋友可以到Zend 的每周總結(jié)（http://www.zend.com/zend/week/week279.php#Heading9）里面看看來(lái)龍去脈，此處不再贅述。5、__toString() 函數(shù)將會(huì)在任何合適的地方被調(diào)用。魔術(shù)方法 __toString() 現(xiàn)在會(huì)在一個(gè)字符串上下文環(huán)境中被調(diào)用。換句話說(shuō)，一個(gè)對(duì)象在任何地方都可以作為一個(gè)字符串來(lái)使用，只要它實(shí)現(xiàn)了 __toString() 函數(shù)。當(dāng)然你實(shí)現(xiàn)的 __toString() 函數(shù)不能拋出異常，否則腳本將會(huì)中止運(yùn)行。以前為防萬(wàn)一，PHP 5.0/5.1會(huì)在必要時(shí)會(huì)把對(duì)象標(biāo)識(shí)(Id)作為一個(gè)字符串返回，這個(gè)特性在 PHP 5.2中已經(jīng)被拋棄。因此這帶來(lái)的問(wèn)題就可能是不能保證一個(gè)對(duì)象的標(biāo)識(shí)總是唯一的。如果你在程序中利用了對(duì)象標(biāo)識(shí)符的唯一性，那這將會(huì)是某種缺陷。如果沒(méi)有實(shí)現(xiàn)類(lèi)的 __toString()函數(shù)但卻把其對(duì)象作為作為一個(gè)字符串來(lái)使用就會(huì)導(dǎo)致一個(gè)“可捕捉的致命錯(cuò)誤”。 還有個(gè)特例，就是對(duì)象也不能作為作為數(shù)組的索引或者鍵名，即使是它有一個(gè) __toString() 方法。以后 PHP 可能會(huì)內(nèi)建一個(gè) Hash機(jī)制來(lái)提供對(duì)對(duì)象唯一性的支持，但就現(xiàn)在來(lái)說(shuō)，你必須自己提供一個(gè)對(duì)象的 hash 算法，或者干脆就用新提供的 SPL 函數(shù)：spl_object_hash()； 6、為在寫(xiě)模式下訪問(wèn) __get() 的返回值這種情況增加了E_NOTICE 級(jí)錯(cuò)誤提示。顯然 __get() 函數(shù)只能在讀模式下返回一個(gè)值，并且也不可能把一個(gè)值寫(xiě)入 __get() 函數(shù)。但在以前的版本中并沒(méi)有為這種不正確的用法給予提示。從 PHP 5.2 開(kāi)始將會(huì)為這種情況拋出一個(gè)E_NOTICE。注意：如果你對(duì) foreach() 和其他的一些更改數(shù)組內(nèi)部指針的函數(shù)也采取了同樣的操作（即給 foreach 所“抽”出來(lái)的值進(jìn)行賦值），那也會(huì)觸發(fā)一個(gè)E_NOTICE ，因?yàn)檫@些“抽”出來(lái)的值都是處于讀模式。如果你的代碼中存在這種情況，那你應(yīng)該把 __get() 函數(shù)的返回值轉(zhuǎn)換為一個(gè)數(shù)組，或者用 SPL 里面的ArrayObject 來(lái)代替這個(gè)數(shù)組。 7、丟棄了抽象靜態(tài)的類(lèi)函數(shù)。由于“筆漏”，PHP 5.0和5.1 版本竟然允許類(lèi)具有抽象靜態(tài)函數(shù)，不過(guò)現(xiàn)在不行了。現(xiàn)在只允許接口有抽象靜態(tài)函數(shù)。 8、其他一些語(yǔ)言特性的改變：－ SPL 新增了正則迭代器(Regex Iterators)、文件對(duì)象（SplFileObject）的CSV 支持等。 － 增加了對(duì) RFC2397 （數(shù)據(jù)流）的支持。－ 增加了對(duì)Apache 2.2的支持。－ 現(xiàn)在可以在上傳文件時(shí)實(shí)時(shí)取得文件的上傳進(jìn)度了。－ 對(duì)PHP或其擴(kuò)展所需 OpenSSL 庫(kù)、PCRE 庫(kù)、MySQL客戶端庫(kù)、PostgreSQL 客戶端庫(kù)、SQLite 庫(kù)等均進(jìn)行更新升級(jí)。最后再來(lái)介紹一下 PHP 運(yùn)行模式方面的改動(dòng)：; 1、首先是 PHP 5.2 改變了 Win32 環(huán)境下 PHPRC 環(huán)境變量的優(yōu)先級(jí)。在以前搜索 php.ini 的路徑順序?yàn)椋骸API 模塊所指定的位置（Apache 2 中的 PHPIniDir 指令，CGI 和 CLI 中的 -c 命令行選項(xiàng)，NSAPI 中的 php_ini 參數(shù)，THTTPD 中的 PHP_INI_PATH 環(huán)境變量） ·HKEY_LOCAL_MACHINESOFTWAREPHPIniFilePath（Windows 注冊(cè)表位置） ·PHPRC 環(huán)境變量 ·當(dāng)前工作目錄（對(duì)于 CLI） ·web 服務(wù)器目錄（對(duì)于 SAPI 模塊）或 PHP 所在目錄（Windows 下其它情況） ·Windows 目錄（C:windows 或 C:winnt），或 –with-config-file-path 編譯時(shí)選項(xiàng)指定的位置現(xiàn)在 PHPRC 環(huán)境變量由第三優(yōu)先權(quán)變?yōu)榈诙?yōu)先權(quán)，高于Windows 注冊(cè)表所指定的位置。 2、PHP 的命令行模式（CLI SAPI）不再在CWD（當(dāng)前工作目錄）里查找 php.ini 或php-cli.ini 文件。在 PHP 5.1.x 中有一個(gè)未公開(kāi)的特性就是 CLI會(huì)自動(dòng)在當(dāng)前目錄中搜索 PHP 的配置文件。這種隨便讀入一個(gè)未經(jīng)許可的配置文件的行為將可能會(huì)導(dǎo)致一個(gè)不可預(yù)知的錯(cuò)誤。在 PHP 5.2 版本里已經(jīng)將該特性移除，不再再在CWD（當(dāng)前工作目錄）里查找 php.ini 或php-cli.ini 文件了。 總結(jié)： 總體來(lái)說(shuō)，從性能上 PHP 5.2 已經(jīng)超越 PHP4.x成為目前速度最快的版本，從語(yǔ)言及安全特性上也是無(wú)出其右。即便是 PHP4.x 有一些代碼緩存工具（如 eAccelerator）可以提高性能，但目前也已經(jīng)有 APC、X-Cache等表示可以支持 5.2 版本（eAccelerator 可能還需要一段時(shí)間來(lái)完善）。雖然 APC 等在性能還略輸于eAccelerator，但加上PHP5.2的種種優(yōu)化措施，至少不會(huì)比 PHP4+eAccelerator 差到哪去更何況還有很要命的安全更新。既然如此，那我們還有什么理由不升級(jí)呢？同時(shí)我也推薦各大虛擬主機(jī)廠商將其服務(wù)器（至少是新增的服務(wù)器）更新為 PHP5.2版本。在不增加性能消耗的基礎(chǔ)上還能為客戶提供更多的語(yǔ)言特性，同時(shí)也增強(qiáng)了產(chǎn)品的競(jìng)爭(zhēng)力，何樂(lè)而不為呢？讓我們開(kāi)始全面進(jìn)入 PHP 5.2 的時(shí)代吧！