PHP確實(shí)十分容易編寫。但是PHP也有一些十分嚴(yán)重的缺陷。下面我會(huì)給出我的理由，為什么PHP不適合于比小型業(yè)余網(wǎng)站更大的網(wǎng)站。

1、對(duì)遞歸的不良支持

遞歸是一種函數(shù)調(diào)用自身的機(jī)制。這是一種強(qiáng)大的特性可以把某些復(fù)雜的東西變得很簡(jiǎn)單。有一個(gè)使用遞歸的例子是快速排序(quicksort)。不幸的是，PHP并不擅長(zhǎng)遞歸。Zeev，一個(gè)PHP開(kāi)發(fā)人員，說(shuō)道：“PHP 4.0(Zend)對(duì)密集數(shù)據(jù)使用了棧方式，而不是使用堆方式。也就是說(shuō)它能容忍的遞歸函數(shù)的數(shù)量限制和其他語(yǔ)言比起來(lái)明顯少。”見(jiàn)bug 1901。這是一個(gè)很不好的借口。每一個(gè)編程語(yǔ)言都應(yīng)該提供良好的遞歸支持。

2、許多PHP模塊都不是線程安全的

在幾年前，Apache發(fā)布了Web服務(wù)器的2.0版。這個(gè)版本支持多線程模式，在這個(gè)模式下，軟件一個(gè)一部分可以同時(shí)運(yùn)行多個(gè)。PHP的發(fā)明者說(shuō)PHP的核心是線程安全的，但是非核心模塊不一定是。但是十次有九次，你想要在PHP腳本中使用這種模塊，但這又使你的腳本不能合適Apache的多線程模式。這也是為什么PHP小組不推薦在Apache 2 的多線程模式下運(yùn)行PHP。不良的多線程模式支持使PHP常被認(rèn)為是Apache 2依然不流行的原因之一。

3、PHP 由于商業(yè)原因而不健全

通過(guò)使用緩存，PHP的性能可以陡增500%[見(jiàn)基準(zhǔn)測(cè)試]。那么為什么緩存沒(méi)有被構(gòu)建在PHP中呢?因?yàn)閆end——PHP的制造者，它在銷售自己的Zend Accelerator，所以當(dāng)然，他們不想拋棄自己的商業(yè)產(chǎn)品這塊肥肉。

但是有另一個(gè)可選擇的： APC. (Zend后來(lái)推出Zend Optimizer，免費(fèi)的加速器——譯者)

4、沒(méi)有命名空間

設(shè)想某個(gè)人制作了一個(gè)PHP模塊用來(lái)閱讀文件。模塊中一個(gè)函數(shù)叫做read。然后另一個(gè)人的模塊可以讀取網(wǎng)頁(yè)的，同樣包含一個(gè)函數(shù)read。然后我們就無(wú)法同時(shí)使用這兩個(gè)模塊了，因?yàn)镻HP不知道你要用哪個(gè)函數(shù)。但是有一個(gè)很簡(jiǎn)單的解決方法，那就是命名空間。曾經(jīng)有人建議PHP5加入這個(gè)特性，但不幸的是他沒(méi)有這么做。現(xiàn)在，沒(méi)有命名空間，每個(gè)函數(shù)都必須加上模塊名作為前綴，來(lái)避免名稱沖突。這導(dǎo)致了函數(shù)名恐怖得長(zhǎng)，例如xsl_xsltprocessor_transform_to_XML讓代碼難于書寫和理解。

5、不標(biāo)準(zhǔn)的日期格式字符

很多程序員對(duì) 日期格式字符 都很熟悉，它是從UNIX和C語(yǔ)言中來(lái)的。其他一些編程語(yǔ)言采用了這個(gè)標(biāo)準(zhǔn)，但是很奇怪的，PHP有它自己的一套完全不兼容的日期格式字符。在C中，“%j”表示一年中的當(dāng)天，在PHP中他表示一個(gè)月中的當(dāng)天。然而使事情更混亂的是：Smarty (一個(gè)很流行的PHP模版引擎)的 strftime 函數(shù)和 date_format 函數(shù)，卻使用了C/UNIX的格式化字符。

6、混亂的許可證

你也許認(rèn)為PHP是免費(fèi)的，所有的在手冊(cè)中提到的PHP模塊也是免費(fèi)的。錯(cuò)了!例如，如果你想在PHP中生成PDF文件，你會(huì)在手冊(cè)中發(fā)現(xiàn)兩個(gè)模塊：PDF 和 ClibPDF。但是這兩個(gè)都是有商業(yè)許可證的。所以，你所使用的每個(gè)模塊，你都要確保你同意他的許可證。

7、不一致的函數(shù)命名規(guī)則

有些函數(shù)名稱是有多個(gè)單詞組成的。一般有三種單詞組合的習(xí)慣：

直接拼接：getnumberoffiles

用下劃線分開(kāi)：get_number_of_files

駱駝法則：getNumberOfFiles

大部分語(yǔ)言選擇其中一中。但是PHP都用到了。

例如，你想要把一些特殊字符轉(zhuǎn)換成HTML實(shí)體，你會(huì)使用函數(shù)htmlentities (直接拼接單詞)。如果你要使用相反的功能，你要用到它的小弟html_entity_decode。由于某些特殊的原因，這個(gè)函數(shù)名是由下劃線分隔單詞。怎么能這樣呢?你知道有一個(gè)函數(shù)叫strpad。或者他是str_pad?每次你都要查看一下到底這個(gè)符號(hào)是什么或者直接等他出現(xiàn)一個(gè)錯(cuò)誤。函數(shù)是不分大小寫的，所以對(duì)于PHP來(lái)說(shuō)rawurldecode 和RawUrlDecode之間沒(méi)有什么區(qū)別。這也很糟糕，因?yàn)閮蓚€(gè)都使用到了同時(shí)他們看上去還不一樣，混淆了閱讀者。

8、魔法引用的地獄

魔法引用(Magic quote)可以保護(hù)PHP腳本免受SQL注入攻擊。這很好。但是出于某些原因，你可以在php.ini中關(guān)閉這個(gè)配置。所以你如果要寫出一個(gè)有彈性的腳本，你總要檢查魔法引用是開(kāi)啟還是關(guān)閉。這樣一個(gè)“特性”應(yīng)該讓編程更簡(jiǎn)單，而事實(shí)上變得更復(fù)雜了。

9、缺少標(biāo)準(zhǔn)框架

一個(gè)成長(zhǎng)中的網(wǎng)站沒(méi)有一個(gè)整體框架，最終會(huì)變成維護(hù)的噩夢(mèng)。一個(gè)框架可以讓很多工作變得簡(jiǎn)單。現(xiàn)在最流行的框架模型時(shí)MVC-模型，在其中表現(xiàn)層、業(yè)務(wù)邏輯和數(shù)據(jù)庫(kù)訪問(wèn)都分離開(kāi)了。

很多PHP網(wǎng)站不使用MVC-模型。他們甚至沒(méi)有一個(gè)框架。甚至現(xiàn)在有一些PHP框架同時(shí)你都可以自己寫一個(gè)，關(guān)于PHP的文章和手冊(cè)沒(méi)有提高框架的一個(gè)字。同時(shí)JSP-開(kāi)發(fā)人員使用像Struts的框架、ASP開(kāi)發(fā)人員使用.net，看起來(lái)好像這些概念都廣泛被PHP開(kāi)發(fā)人員所了解。這就說(shuō)明了PHP實(shí)際上到底是多專業(yè)。

總結(jié)

什么問(wèn)題?

對(duì)于非常小的項(xiàng)目，它可以是一個(gè)十分符合人意的編程語(yǔ)言。但是對(duì)于較大的和更為復(fù)雜的項(xiàng)目，PHP就顯出他的薄弱了。當(dāng)你不斷地摸索之后，你會(huì)發(fā)現(xiàn)我提到的某些問(wèn)題的解決方案。所以，當(dāng)解決方案已知之后，為什么不能修正他呢?另外，為什么這些修補(bǔ)不在手冊(cè)中提到呢? 一個(gè)開(kāi)源的語(yǔ)言十分流行是一件好事。但不幸得是，它不是一個(gè)偉大的語(yǔ)言。我希望所有的問(wèn)題能有一天得到解決(也許在PHP6)，然后，我們就將擁有一個(gè)開(kāi)源語(yǔ)言，他既開(kāi)源，又好用。

到現(xiàn)在，當(dāng)你要啟動(dòng)一個(gè)多于5個(gè)腳本頁(yè)面的項(xiàng)目的時(shí)候，你最好考慮C#/ASP.NET或者 Java/JSP或者也許Python同樣是一個(gè)更好的選擇。