⑴ 簡評用php開發大型系統的缺點
筆者在過去的四年裡一直致力於PHP應用的開發 PHP確實十分容易編寫 但是PHP也有一些十分嚴重的缺陷
下面筆者會給出自己的理由 為什麼PHP不適合於比小型業余網站更大的網站
對遞歸的不良支持
遞歸是一種函數調用自身的機制 這是一種強大的特性可以把某些復雜的東西變得很簡單 有一個使用遞歸的例子是快速排序（quicksort） 不幸的是 PHP並不擅長遞歸 Zeev 一個PHP開發人員 說道 PHP （Zend）對密集數據使用了棧方式 而不是使用堆方式 也就是說它能容忍的遞歸函數的數量限制和其他語言比起來明顯少 見bug 這是一個很不好的借口 每一個編程語言都應該提供良好的遞歸支持
許多PHP模塊都不是線程安全的
在幾年前 Apache發布了Web伺服器的 版 這個版本支持多線程模式 在這個模式下 軟體一個一部分可以同時運行多個 PHP的發明者說PHP的核心是線程安全的 但是非核心模塊不一定是 但是十次有九次 你想要在PHP腳本中使用這種模塊 但這又使你的腳本不能合適Apache的多線程模式 這也是為什麼PHP小組不推薦在Apache 的多線程模式下運行PHP 不良的多線程模式支持使PHP常被認為是Apache 依然不流行的原因之一
PHP 由於商業原因而不健全
通過使用緩存 PHP的性能可以陡增 %[見基準測試] 那麼為什麼緩存沒有被構建在PHP中呢？因為Zend——PHP的製造者 它在銷售自己的Zend Accelerator 所以當然 他們不想拋棄自己的商業產品這塊肥肉
但是有另一個可選擇的 APC （Zend後來推出Zend Optimizer 免費的加速器——譯者）
沒有命名空間
設想某個人製作了一個PHP模塊用來閱讀文件 模塊中一個函數叫做read 然後另一個人的模塊可以讀取網頁的 同樣包含一個函數read 然後我們就無法同時使用這兩個模塊了 因為PHP不知道你要用哪個函數
但是有一個很簡單的解決方法 那就是命名空間 曾經有人建議PHP 加入這個特性 但不幸得是他沒有這么做 現在 沒有命名空間 每個函數都必須加上模塊名作為前綴 來避免名稱沖突 這導致了函數名恐怖得長 例如xsl_xsltprocessor_transform_to_xml讓代碼難於書寫和理解
不標準的日期格式字元
很多敏敏程序員對 日期格式字元 都很熟悉 它是從UNIX和氏握C語言中來的 其他一些編程語言採用了這個標准 但是很奇怪的 PHP有它自己的一套完全不兼容的日期格式字元 在C中 %j 表示一年中的當天 在PHP中他表示一個月中的當天 然而使事情更混亂的是 Smarty （一個很流行的PHP模版引擎）的 strftime 函數和 date_format 函數 卻使用了C/UNIX的格式化字元
混亂的許可證
你也許認為PHP是免費的 所有的在手冊中提到的PHP模塊也是免費的 錯了！例如 如果你想在PHP中生成PDF文件 你會在手冊中發現兩個模塊 PDF 和 ClibPDF 但是這兩個都是有商業許可證的 所以 你所使用的每個模塊 你都要確保你同意他的許可證
不一致的函數命名規則
有些函數名稱是有多個單片語成的 一般有三種單詞殲拿慶組合的習慣
直接拼接 getnumberoffiles 用下劃線分開 get_number_of_files 駱駝法則 getNumberOfFiles 大部分語言選擇其中一中 但是PHP都用到了
例如 你想要把一些特殊字元轉換成HTML實體 你會使用函數entities （直接拼接單詞） 如果你要使用相反的功能 你要用到它的小弟弟_entity_decode 由於某些特殊的原因 這個函數名是由下劃線分隔單詞 怎麼能這樣呢？你知道有一個函數叫strpad 或者他是str_pad？每次你都要查看一下到底這個符號是什麼或者直接等他出現一個錯誤 函數是不分大小寫的 所以對於PHP來說rawurldecode 和RawUrlDecode之間沒有什麼區別 這也很糟糕 因為兩個都使用到了同時他們看上去還不一樣 混淆了閱讀者
魔法引用的地獄
魔法引用（Magic quote）可以保護PHP腳本免受SQL注入攻擊 這很好 但是出於某些原因 你可以在php ini中關閉這個配置 所以你如果要寫出一個有彈性的腳本 你總要檢查魔法引用是開啟還是關閉 這樣一個 特性 應該讓編程更簡單 而事實上變得更復雜了
缺少標准框架
一個成長中的網站沒有一個整體框架 最終會變成維護的噩夢 一個框架可以讓很多工作變得簡單 現在最流行的框架模型時MVC 模型 在其中表現層 業務邏輯和資料庫訪問都分離開了
很多PHP網站不使用MVC 模型 他們甚至沒有一個框架 甚至現在有一些PHP框架同時你都可以自己寫一個 關於PHP的文章和手冊沒有提高框架的一個字 同時JSP 開發人員使用像Struts的框架 ASP開發人員使用 Net 看起來好像這些概念都廣泛被PHP開發人員所了解 這就說明了PHP實際上到底是多專業
總結
什麼問題?
對於非常小的項目 它可以是一個十分符合人意的編程語言 但是對於較大的和更為復雜的項目 PHP就顯出他的薄弱了 當你不斷地摸索之後 你會發現筆者提到的某些問題的解決方案 所以 當解決方案已知之後 為什麼不能修正他呢？另外為什麼這些修補不在手冊中提到呢？
一個開源的語言十分流行是一件好事 但不幸得是 它不是一個偉大的語言 筆者希望所有的問題能有一天得到解決（也許在PHP ？） 然後我們就將擁有一個開源語言 他既開源 又好用
lishixin/Article/program/PHP/201311/21478