目前學習PHP很多朋友，在平時的日常程序開發工程中總會遇到各種各樣的問題，本篇經驗將為大家介紹PHP開發中10個最常見的問題，希望能夠對朋友有所幫助。
錯誤1：foreach循環后留下懸掛指針
在foreach循環中，如果我們需要更改迭代的元素或是為了提高效率，運用引用是一個好辦法：
|
1
2
3
4
5
|
$arr = array(1, 2, 3, 4); foreach ($arr as &$value) { $value = $value * 2; } // $arr is now array(2, 4, 6, 8) |
這里有個問題很多人會迷糊。循環結束后，value并未銷毀，value其實是數組中最后一個元素的引用，這樣在后續對$value的使用中，如果不知道這一點，會引發一些莫名奇妙的錯誤:)看看下面這段代碼：
|
1
2
3
4
5
6
7
8
|
$array = [1, 2, 3]; echo implode(',', $array), "\n"; foreach ($array as &$value) {} // by reference echo implode(',', $array), "\n"; foreach ($array as $value) {} // by value (i.e., copy) echo implode(',', $array), "\n"; |
上面代碼的運行結果如下：
|
1
2
3
|
1,2,3 1,2,3 1,2,2 |
你猜對了嗎？為什么是這個結果呢？
我們來分析下。第一個循環過后，$value是數組中最后一個元素的引用。第二個循環開始：
第一步：復制arr[0]到value（注意此時value是arr[2]的引用），這時數組變成[1,2,1]
第二步：復制arr[1]到value，這時數組變成[1,2,2]
第三步：復制arr[2]到value，這時數組變成[1,2,2]
綜上，最終結果就是1,2,2
避免這種錯誤最好的辦法就是在循環后立即用unset函數銷毀變量：
|
1
2
3
4
5
|
$arr = array(1, 2, 3, 4); foreach ($arr as &$value) { $value = $value * 2; } unset($value); // $value no longer references $arr[3] |
錯誤2：對isset()函數行為的錯誤理解
對于isset()函數，變量不存在時會返回false，變量值為null時也會返回false。這種行為很容易把人弄迷糊。。。看下面的代碼：
|
1
2
3
4
|
$data = fetchRecordFromStorage($storage, $identifier); if (!isset($data['keyShouldBeSet']) { // do something here if 'keyShouldBeSet' is not set } |
寫這段代碼的人本意可能是如果data[′keyShouldBeSet′]未設置，則執行對應邏輯。但問題在于即使data['keyShouldBeSet']已設置，但設置的值為null，還是會執行對應的邏輯，這就不符合代碼的本意了。
下面是另外一個例子：
|
1
2
3
4
5
6
7
8
9
|
if ($_POST['active']) { $postData = extractSomething($_POST); } // ... if (!isset($postData)) { echo 'post not active'; } |
上面的代碼假設POST[′active′]為真，那么postData應該被設置，因此isset(postData)會返回true。反之，上面代碼假設isset(postData)返回false的唯一途徑就是$_POST['active']也返回false。
真是這樣嗎？當然不是！
即使POST[′active′]返回true，postData也有可能被設置為null，這時isset($postData)就會返回false。這就不符合代碼的本意了。
如果上面代碼的本意僅是檢測$_POST['active']是否為真，下面這樣實現會更好：
|
1
2
3
4
5
6
7
8
9
|
if ($_POST['active']) { $postData = extractSomething($_POST); } // ... if ($_POST['active']) { echo 'post not active'; } |
判斷一個變量是否真正被設置（區分未設置和設置值為null），array_key_exists()函數或許更好。重構上面的第一個例子，如下：
|
1
2
3
4
|
$data = fetchRecordFromStorage($storage, $identifier); if (! array_key_exists('keyShouldBeSet', $data)) { // do this if 'keyShouldBeSet' isn't set } |
另外，結合get_defined_vars()函數，我們可以更加可靠的檢測變量在當前作用域內是否被設置：
|
1
2
3
|
if (array_key_exists('varShouldBeSet', get_defined_vars())) { // variable $varShouldBeSet exists in current scope } |
錯誤3：混淆返回值和返回引用
考慮下面的代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
class Config { private $values = []; public function getValues() { return $this->values; } } $config = new Config(); $config->getValues()['test'] = 'test'; echo $config->getValues()['test']; |
運行上面的代碼，將會輸出下面的內容：
|
1
|
PHP Notice: Undefined index: test in /path/to/my/script.php on line 21 |
問題出在哪呢？問題就在于上面的代碼混淆了返回值和返回引用。在PHP中，除非你顯示的指定返回引用，否則對于數組PHP是值返回，也就是數組的拷貝。因此上面代碼對返回數組賦值，實際是對拷貝數組進行賦值，非原數組賦值。
|
1
2
3
4
5
6
7
|
// getValues() returns a COPY of the $values array, so this adds a 'test' element // to a COPY of the $values array, but not to the $values array itself. $config->getValues()['test'] = 'test'; // getValues() again returns ANOTHER COPY of the $values array, and THIS copy doesn't // contain a 'test' element (which is why we get the "undefined index" message). echo $config->getValues()['test']; |
下面是一種可能的解決辦法，輸出拷貝的數組，而不是原數組：
|
1
2
3
|
$vals = $config->getValues(); $vals['test'] = 'test'; echo $vals['test']; |
如果你就是想要改變原數組，也就是要反回數組引用，那應該如何處理呢？辦法就是顯示指定返回引用即可：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
class Config { private $values = []; // return a REFERENCE to the actual $values array public function &getValues() { return $this->values; } } $config = new Config(); $config->getValues()['test'] = 'test'; echo $config->getValues()['test']; |
經過改造后，上面代碼將會像你期望那樣會輸出test。
我們再來看一個例子會讓你更迷糊的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
class Config { private $values; // using ArrayObject rather than array public function __construct() { $this->values = new ArrayObject(); } public function getValues() { return $this->values; } } $config = new Config(); $config->getValues()['test'] = 'test'; echo $config->getValues()['test']; |
如果你想的是會和上面一樣輸出“ Undefined index”錯誤，那你就錯了。代碼會正常輸出“test”。原因在于PHP對于對象默認就是按引用返回的，而不是按值返回。
綜上所述，我們在使用函數返回值時，要弄清楚是值返回還是引用返回。PHP中對于對象，默認是引用返回，數組和內置基本類型默認均按值返回。這個要與其它語言區別開來（很多語言對于數組是引用傳遞）。
像其它語言，比如java或C#，利用getter或setter來訪問或設置類屬性是一種更好的方案，當然PHP默認不支持，需要自己實現：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class Config { private $values = []; public function setValue($key, $value) { $this->values[$key] = $value; } public function getValue($key) { return $this->values[$key]; } } $config = new Config(); $config->setValue('testKey', 'testValue'); echo $config->getValue('testKey'); // echos 'testValue' |
上面的代碼給調用者可以訪問或設置數組中的任意值而不用給與數組public訪問權限。感覺怎么樣:)
錯誤4：在循環中執行sql查詢
在PHP編程中發現類似下面的代碼并不少見：
|
1
2
3
4
5
|
$models = []; foreach ($inputValues as $inputValue) { $models[] = $valueRepository->findByValue($inputValue); } |
當然上面的代碼是沒有什么錯誤的。問題在于我們在迭代過程中$valueRepository->findByValue()可能每次都執行了sql查詢：
|
1
|
$result = $connection->query("SELECT `x`,`y` FROM `values` WHERE `value`=" . $inputValue); |
如果迭代了10000次，那么你就分別執行了10000次sql查詢。如果這樣的腳本在多線程程序中被調用，那很可能你的系統就掛了。。。
在編寫代碼過程中，你應該要清楚什么時候應該執行sql查詢，盡可能一次sql查詢取出所有數據。
有一種業務場景，你很可能會犯上述錯誤。假設一個表單提交了一系列值（假設為IDs），然后為了取出所有ID對應的數據，代碼將遍歷IDs，分別對每個ID執行sql查詢，代碼如下所示：
|
1
2
3
4
5
|
$data = []; foreach ($ids as $id) { $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` = " . $id); $data[] = $result->fetch_row(); } |
但同樣的目的可以在一個sql中更加高效的完成，代碼如下：
|
1
2
3
4
5
6
7
|
$data = []; if (count($ids)) { $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` IN (" . implode(',', $ids)); while ($row = $result->fetch_row()) { $data[] = $row; } } |
錯誤5：內存使用低效和錯覺
一次sql查詢獲取多條記錄比每次查詢獲取一條記錄效率肯定要高，但如果你使用的是php中的mysql擴展，那么一次獲取多條記錄就很可能會導致內存溢出。
我們可以寫代碼來實驗下（測試環境： 512MB RAM、MySQL、php-cli）：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
// connect to mysql $connection = new mysqli('localhost', 'username', 'password', 'database'); // create table of 400 columns $query = 'CREATE TABLE `test`(`id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT'; for ($col = 0; $col < 400; $col++) { $query .= ", `col$col` CHAR(10) NOT NULL"; } $query .= ');'; $connection->query($query); // write 2 million rows for ($row = 0; $row < 2000000; $row++) { $query = "INSERT INTO `test` VALUES ($row"; for ($col = 0; $col < 400; $col++) { $query .= ', ' . mt_rand(1000000000, 9999999999); } $query .= ')'; $connection->query($query); } |
現在來看看資源消耗：
|
1
2
3
4
5
6
7
8
9
|
// connect to mysql $connection = new mysqli('localhost', 'username', 'password', 'database'); echo "Before: " . memory_get_peak_usage() . "\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 1'); echo "Limit 1: " . memory_get_peak_usage() . "\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 10000'); echo "Limit 10000: " . memory_get_peak_usage() . "\n"; |
輸出結果如下：
|
1
2
3
|
Before: 224704 Limit 1: 224704 Limit 10000: 224704 |
根據內存使用量來看，貌似一切正常。為了更加確定，試著一次獲取100000條記錄，結果程序得到如下輸出：
|
1
2
|
PHP Warning: mysqli::query(): (HY000/2013): Lost connection to MySQL server during query in /root/test.php on line 11 |
這是怎么回事呢？
問題出在php的mysql模塊的工作方式，mysql模塊實際上就是libmysqlclient的一個代理。在查詢獲取多條記錄的同時，這些記錄會直接 保存在內存中。由于這塊內存不屬于php的內存模塊所管理，所以我們調用memory_get_peak_usage()函數所獲得的值并非真實使用內存 值，于是便出現了上面的問題。
我們可以使用mysqlnd來代替mysql，mysqlnd編譯為php自身擴展，其內存使用由php內存管理模塊所控制。如果我們用mysqlnd來實現上面的代碼，則會更加真實的反應內存使用情況：
|
1
2
3
|
Before: 232048 Limit 1: 324952 Limit 10000: 32572912 |
更加糟糕的是，根據php的官方文檔，mysql擴展存儲查詢數據使用的內存是mysqlnd的兩倍，因此原來的代碼使用的內存是上面顯示的兩倍左右。
為了避免此類問題，可以考慮分幾次完成查詢，減小單次查詢數據量：
|
1
2
3
4
5
6
7
8
|
$totalNumberToFetch = 10000; $portionSize = 100; for ($i = 0; $i <= ceil($totalNumberToFetch / $portionSize); $i++) { $limitFrom = $portionSize * $i; $res = $connection->query( "SELECT `x`,`y` FROM `test` LIMIT $limitFrom, $portionSize"); } |
聯系上面提到的錯誤4可以看出，在實際的編碼過程中，要做到一種平衡，才能既滿足功能要求，又能保證性能。
錯誤6：忽略Unicode/UTF-8問題
php編程中，在處理非ascii字符時，會遇到一些問題，要很小心的去對待，要不然就會錯誤遍地。舉個簡單的例子，strlen(name)，如果name包含非ascii字符，那結果就有些出乎意料。在此給出一些建議，盡量避免此類問題：
如果你對unicode和utf-8不是很了解，那么你至少應該了解一些基礎。推薦閱讀這篇文章。
最好使用mb_*函數來處理字符串，避免使用老的字符串處理函數。這里要確保PHP的“multibyte”擴展已開啟。
數據庫和表最好使用unicode編碼。
知道jason_code()函數會轉換非ascii字符，但serialize()函數不會。
php代碼源文件最好使用不含bom的utf-8格式。
在此推薦一篇文章，更詳細的介紹了此類問題： UTF-8 Primer for PHP and MySQL
錯誤7：假定$_POST總是包含POST數據
PHP中的$_POST并非總是包含表單POST提交過來的數據。假設我們通過 jQuery.ajax() 方法向服務器發送了POST請求：
|
1
2
3
4
5
6
7
|
// js $.ajax({ url: 'http://my.site/some/path', method: 'post', data: JSON.stringify({a: 'a', b: 'b'}), contentType: 'application/json'}); |
注意代碼中的 contentType: ‘application/json' ，我們是以json數據格式來發送的數據。在服務端，我們僅輸出$_POST數組：
|
1
2
|
// php var_dump($_POST); |
你會很驚奇的發現，結果是下面所示：
|
1
|
array(0) { } |
為什么是這樣的結果呢？我們的json數據 {a: ‘a', b: ‘b'} 哪去了呢？
答案就是PHP僅僅解析Content-Type為 application/x-www-form-urlencoded 或 multipart/form-data的Http請求。之所以這樣是因為歷史原因，PHP最初實現$_POST時，最流行的就是上面兩種類型。因此雖說現在有些類型（比如application/json）很流行，但PHP中還是沒有去實現自動處理。
因為POST是全局變量，所以更改_POST會全局有效。因此對于Content-Type為 application/json 的請求，我們需要手工去解析json數據，然后修改$_POST變量。
|
1
2
|
// php $_POST = json_decode(file_get_contents('php://input'), true); |
此時，我們再去輸出$_POST變量，則會得到我們期望的輸出：
|
1
|
array(2) { ["a"]=> string(1) "a" ["b"]=> string(1) "b" } |
錯誤8：認為PHP支持字符數據類型
看看下面的代碼，猜測下會輸出什么：
|
1
2
3
|
for ($c = 'a'; $c <= 'z'; $c++) { echo $c . "\n"; } |
如果你的回答是輸出'a'到'z'，那么你會驚奇的發現你的回答是錯誤的。
不錯，上面的代碼的確會輸出'a'到'z'，但除此之外，還會輸出'aa'到'yz'。我們來分析下為什么會是這樣的結果。
在PHP中不存在char數據類型，只有string類型。明白這點，那么對'z'進行遞增操作，結果則為'aa'。對于字符串比較大小，學過C的應該都知道，'aa'是小于'z'的。這也就解釋了為何會有上面的輸出結果。
如果我們想輸出'a'到'z'，下面的實現是一種不錯的辦法：
|
1
2
3
|
for ($i = ord('a'); $i <= ord('z'); $i++) { echo chr($i) . "\n"; } |
或者這樣也是OK的：
|
1
2
3
4
5
|
$letters = range('a', 'z'); for ($i = 0; $i < count($letters); $i++) { echo $letters[$i] . "\n"; } |
錯誤9：忽略編碼標準
雖說忽略編碼標準不會導致錯誤或是bug，但遵循一定的編碼標準還是很重要的。
沒有統一的編碼標準會使你的項目出現很多問題。最明顯的就是你的項目代碼不具有一致性。更壞的地方在于，你的代碼將更加難以調試、擴展和維護。這也就意味著你的團隊效率會降低，包括做一些很多無意義的勞動。
對于PHP開發者來說，是比較幸運的。因為有PHP編碼標準推薦（PSR），由下面5個部分組成：
PSR-0：自動加載標準
PSR-1：基本編碼標準
PSR-2：編碼風格指南
PSR-3：日志接口標準
PSR-4：自動加載
PSR最初由PHP社區的幾個大的團體所創建并遵循。Zend, Drupal, Symfony, Joomla及其它的平臺都為此標準做過貢獻并遵循這個標準。即使是PEAR，早些年也想讓自己成為一個標準，但現在也加入了PSR陣營。
在某些情況下，使用什么編碼標準是無關緊要的，只要你使用一種編碼風格并一直堅持使用即可。但是遵循PSR標準不失為一個好辦法，除非你有什么特殊的原因要 自己弄一套。現在越來越多的項目都開始使用PSR，大部分的PHP開發者也在使用PSR，因此使用PSR會讓新加入你團隊的成員更快的熟悉項目，寫代碼時 也會更加舒適。
錯誤10：錯誤使用empty()函數
一些PHP開發人員喜歡用empty()函數去對變量或表達式做布爾判斷，但在某些情況下會讓人很困惑。
首先我們來看看PHP中的數組Array和數組對象ArrayObject。看上去好像沒什么區別，都是一樣的。真的這樣嗎？
|
1
2
3
4
5
6
|
// PHP 5.0 or later: $array = []; var_dump(empty($array)); // outputs bool(true) $array = new ArrayObject(); var_dump(empty($array)); // outputs bool(false) // why don't these both produce the same output? |
讓事情變得更復雜些，看看下面的代碼：
|
1
2
3
4
5
|
// Prior to PHP 5.0: $array = []; var_dump(empty($array)); // outputs bool(false) $array = new ArrayObject(); var_dump(empty($array)); // outputs bool(false) |
很不幸的是，上面這種方法很受歡迎。例如，在Zend Framework 2中，Zend\Db\TableGateway 在 TableGateway::select() 結果集上調用 current() 方法返回數據集時就是這么干的。開發人員很容易就會踩到這個坑。
為了避免這些問題，檢查一個數組是否為空最后的辦法是用 count() 函數：
|
1
2
3
4
5
|
// Note that this work in ALL versions of PHP (both pre and post 5.0): $array = []; var_dump(count($array)); // outputs int(0) $array = new ArrayObject(); var_dump(count($array)); // outputs int(0) |
在這順便提一下，因為PHP中會將數值0認為是布爾值false，因此 count() 函數可以直接用在 if 條件語句的條件判斷中來判斷數組是否為空。另外，count() 函數對于數組來說復雜度為O(1)，因此用 count() 函數是一個明智的選擇。
再來看一個用 empty() 函數很危險的例子。當在魔術方法 __get() 中結合使用 empty() 函數時，也是很危險的。我們來定義兩個類，每個類都有一個 test 屬性。
首先我們定義 Regular 類，有一個 test 屬性：
|
1
2
3
4
|
class Regular { public $test = 'value'; } |
然后我們定義 Magic 類，并用 __get() 魔術方法來訪問它的 test 屬性：
|
1
2
3
4
5
6
7
8
9
10
11
|
class Magic { private $values = ['test' => 'value']; public function __get($key) { if (isset($this->values[$key])) { return $this->values[$key]; } } } |
好了。我們現在來看看訪問各個類的 test 屬性會發生什么：
|
1
2
3
4
|
$regular = new Regular(); var_dump($regular->test); // outputs string(4) "value" $magic = new Magic(); var_dump($magic->test); // outputs string(4) "value" |
到目前為止，都還是正常的，沒有讓我們感到迷糊。
但在 test 屬性上使用 empty() 函數會怎么樣呢？
|
1
2
|
var_dump(empty($regular->test)); // outputs bool(false) var_dump(empty($magic->test)); // outputs bool(true) |
結果是不是很意外？
很不幸的是，如果一個類使用魔法 __get() 函數來訪問類屬性的值，沒有簡單的方法來檢查屬性值是否為空或是不存在。在類作用域外，你只能檢查是否返回 null 值，但這并不一定意味著沒有設置相應的鍵，因為鍵值可以被設置為 null 。
相比之下，如果我們訪問 Regular 類的一個不存在的屬性，則會得到一個類似下面的Notice消息：
|
1
2
3
4
|
Notice: Undefined property: Regular::$nonExistantTest in /path/to/test.php on line 10 Call Stack: 0.0012 234704 1. {main}() /path/to/test.php:0 |
因此，對于 empty() 函數，我們要小心的使用，要不然的話就會結果出乎意料，甚至潛在的誤導你。
