php魔法函數

1. php SESSION用法 $_SESSION['']初始值

注意，在使用session之前一定要調用

<?php
session_start();

開始會話，否則會出錯。在你的代碼里我看不到。

$_SESSION數組的使用類似於普通數組。但它是有」魔法「的。當頁面結束後，$_SESSION的內容會被PHP解析器自動保存下來，同時在用戶的瀏覽器留下一個cookie。下次用戶訪問時，使用該cookie繼續會話。

所以，檢查一個session是否存在和普通數組一樣：

<?php
//正確，檢查flag下標是否設置
if(isset($_SESSION['flag']))...
//錯誤，會導致警告，下標不存在
if($_SESSION['flag'])...
//存儲一個session值
$_SESSION['flag']=1;
//刪除一個session值
unset($_SESSION['flag']);

一個沒有設置的session是沒有初始值的。就像你初始化一個空數組一樣。

2. php做優化包括哪些內容

1：單引號代替雙引號，雙引號會去找變數。
2：方法定義為static，性能提升4倍。
3：$arr['id']的性能是$arr[id]的7倍。
4：echo性能快，盡量使用echo $a,$b,$c而非echo $a.$b.$c。
5：循環之前確定循環次數，盡量用foreach。
6：注銷不使用的變數，節省內存。
7：盡量不使用魔法函數：__get、__set等。
8：require_once()會檢查是否載入，消耗內存。
9：include文件時使用絕對路徑，省去查找的時間。
10：腳本開始執行時間$_SERVER[『REQUEST_TIME』]要好於time()。
11：正則效率低，用函數代替。
12：str_replace函數比preg_replace函數快，但strtr函數的效率是str_replace函數的四倍。
13：接收客串的效率比接收數組的效率高。
14：switch case好於多個if else。
15：用@屏蔽錯誤消息的方法很低效。
16：打開apache的mod_deflate模塊，可以提高網頁的瀏覽速度。
17：資料庫連接當使用完畢時應關掉，不要用長連接。
18：錯誤消息代價昂貴。
19：在方法中遞增局部變數，速度是最快的。幾乎與在函數中調用局部變數的速度相當。
20：遞增一個全局變數要比遞增一個局部變數慢2倍。
21：遞增一個對象屬性（如：$this->prop++）要比遞增一個局部變數慢3倍。
22：遞增一個未預定義的局部變數要比遞增一個預定義的局部變數慢9至10倍。
23：僅定義一個局部變數而沒在函數中調用它，同樣會減慢速度（其程度相當於遞增一個局部變數）。PHP大概會檢查看是否存在全局變數。
24：方法調用看來與類中定義的方法的數量無關，因為我（在測試方法之前和之後都）添加了10個方法，但性能上沒有變化。
25：派生類中的方法運行起來要快於在基類中定義的同樣的方法。
26：調用帶有一個參數的空函數，其花費的時間相當於執行7至8次的局部變數遞增操作。類似的方法調用所花費的時間接近於15次的局部變數遞增操作。
27：Apache解析一個PHP腳本的時間要比解析一個靜態HTML頁面慢2至10倍。盡量多用靜態HTML頁面，少用腳本。
28：盡量做緩存，可使用memcached。memcached是一款高性能的內存對象緩存系統，可用來加速動態Web應用程序，減輕資料庫負載。對運算碼 (OP code)的緩存很有用，使得腳本不必為每個請求做重新編譯。
29：當操作字元串並需要檢驗其長度是否滿足某種要求時，你想當然地會使用strlen()函數。此函數執行起來相當快，因為它不做任何計算，只返回在zval 結構（C的內置數據結構，用於存儲PHP變數）中存儲的已知字元串長度。但是，由於strlen()是函數，多多少少會有些慢，因為函數調用會經過諸多步驟，如字母小寫化（譯註：指函數名小寫化，PHP不區分函數名大小寫）、哈希查找，會跟隨被調用的函數一起執行。在某些情況下，你可以使用isset() 技巧加速執行你的代碼。
30：當執行變數$i的遞增或遞減時，$i++會比++$i慢一些。這種差異是PHP特有的，並不適用於其他語言，所以請不要修改你的C或Java代碼並指望它們能立即變快，沒用的。++$i更快是因為它只需要3條指令(opcodes)，$i++則需要4條指令。後置遞增實際上會產生一個臨時變數，這個臨時變數隨後被遞增。而前置遞增直接在原值上遞增。這是最優化處理的一種，正如Zend的PHP優化器所作的那樣。牢記這個優化處理不失為一個好主意，因為並不是所有的指令優化器都會做同樣的優化處理，並且存在大量沒有裝配指令優化器的互聯網服務提供商（ISPs）和伺服器。
31：並不是事必面向對象(OOP)，面向對象往往開銷很大，每個方法和對象調用都會消耗很多內存。
32：盡量採用大量的PHP內置函數。
33：如果在代碼中存在大量耗時的函數，你可以考慮用C擴展的方式實現它們。
34：mod_zip可作為Apache模塊，用來即時壓縮你的數據，並可讓數據傳輸量降低80%。
35：在可以用file_get_contents替代file、fopen、feof、fgets等系列方法的情況下，盡量用 file_get_contents，因為他的效率高得多！但是要注意file_get_contents在打開一個URL文件時候的PHP版本問題。
36：盡量的少進行文件操作，雖然PHP的文件操作效率也不低的。
37：優化Select SQL語句，在可能的情況下盡量少的進行Insert、Update操作(在update上，我被惡批過)。
38：循環內部不要聲明變數，尤其是大變數：對象。
39：多維數組盡量不要循環嵌套賦值。
40：在可以用PHP內部字元串操作函數的情況下，不要用正則表達式。
41：foreach效率更高，盡量用foreach代替while和for循環。
42：用i+=1代替i=i+1。符合c/c++的習慣，效率還高。
43：對global變數，應該用完就unset()掉。

3. 為什麼說用PHP開發大型系統令人不爽

筆者在過去的四年裡一直致力於PHP應用的開發 PHP確實十分容易編寫 但是PHP也有一些十分嚴重的缺陷

下面筆者會給出自己的理由 為什麼PHP不適合於比小型業余網站更大的網站

對遞歸的不良支持 遞歸是一種函數調用自身的機制 這是一種強大的特性可以把某些復雜的東西變得很簡單 有一個使用遞歸的例子是快速排序（quicksort） 不幸的是 PHP並不擅長遞歸 Zeev 一個PHP開發人員 說道 PHP （Zend）對密集數據使用了棧方式 而不是使用堆方式 也就是說它能容忍的遞歸函數的數量限制和其他語言比起來明顯少 見bug 這液虧爛是一個很不好的借口 每一個編程語言都應該提供良好的遞歸支持

許多PHP模塊都不是線程安全的 在幾年前 Apache發布了Web伺服器的 版 這個版本支持多線程模式 在這個模式下 軟體一個一部分可以同時運行多個 PHP的發明者說PHP的核心是線程安全的 但是非核心模塊不一定是 但是十次有九次 你想要在PHP腳本中使用這種模塊 但這又使你的腳本不能合適Apache的多線程模式 這也是為什麼PHP小組不推薦在Apache 的多線程模式下運行PHP 不良的多線程模式支持使PHP常被認為是Apache 依然不流行的原因之一

請閱讀這篇討論 Slashdot: Sites Rejecting 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 ？） 然後我們就將擁有一個開源語言 他既開源 又好用

到現在 當你要啟動一個多於 個腳本頁面的項目的時候 你最好考慮C#/ASP NET 或者 Java/JSP或者也許Python同樣是一個更好的選擇