十個PHP開發者最容易犯的錯誤

　　PHP 語言讓 WEB 端程式設計變得簡單，這也是它能流行起來的原因。但也是因為它的簡單，PHP 也慢慢發展成一個相對複雜的語言，層出不窮的框架，各種語言特性和版本差異都時常讓搞的我們頭大，不得不浪費大量時間去除錯。這篇文章列出了十個最容易出錯的地方，值得我們去注意。

　易犯錯誤 #1: 在 foreach迴圈後留下陣列的引用

　　還不清楚 PHP 中 foreach 遍歷的工作原理？如果你在想遍歷陣列時運算元組中每個元素，在 foreach 迴圈中使用引用會十分方便，例如

$arr = array(1, 2, 3, 4);
foreach ($arr as &$value) {
        $value = $value * 2;
}
// $arr 現在是 array(2, 4, 6, 8)

　　問題是，如果你不注意的話這會導致一些意想不到的負面作用。在上述例子，在程式碼執行完以後，$value 仍保留在作用域內，並保留著對陣列最後一個元素的引用。之後與 $value 相關的操作會無意中修改陣列中最後一個元素的值。

　　你要記住 foreach 並不會產生一個塊級作用域。因此，在上面例子中 $value 是一個全域性引用變數。在 foreach 遍歷中，每一次迭代都會形成一個對 $arr 下一個元素的引用。當遍歷結束後， $value 會引用 $arr 的最後一個元素，並保留在作用域中

　　這種行為會導致一些不易發現的，令人困惑的bug，以下是一個例子

$array = [1, 2, 3];
echo implode(',', $array), "\n";

foreach ($array as &$value) {}    // 通過引用遍歷
echo implode(',', $array), "\n";

foreach ($array as $value) {}     // 通過賦值遍歷
echo implode(',', $array), "\n";

　　以上程式碼會輸出

1,2,3
1,2,3
1,2,2

　　你沒有看錯，最後一行的最後一個值是 2 ，而不是 3 ，為什麼？

　　在完成第一個 foreach 遍歷後， $array 並沒有改變，但是像上述解釋的那樣， $value 留下了一個對 $array 最後一個元素的危險的引用（因為 foreach 通過引用獲得 $value ）

　　這導致當執行到第二個 foreach ，這個"奇怪的東西"發生了。當 $value 通過賦值獲得， foreach 按順序複製每個 $array 的元素到 $value 時，第二個 foreach 裡面的細節是這樣的

• 第一步：複製 $array[0] （也就是 1 ）到 $value （$value 其實是 $array最後一個元素的引用，即 $array[2]），所以 $array[2] 現在等於 1。所以 $array 現在包含 [1, 2, 1]
• 第二步：複製 $array[1]（也就是 2 ）到 $value （ $array[2] 的引用），所以 $array[2] 現在等於 2。所以 $array 現在包含 [1, 2, 2]
• 第三步：複製 $array[2]（現在等於 2 ） 到 $value （ $array[2] 的引用），所以 $array[2] 現在等於 2 。所以 $array 現在包含 [1, 2, 2]

　　為了在 foreach 中方便的使用引用而免遭這種麻煩，請在 foreach 執行完畢後 unset() 掉這個保留著引用的變數。例如

$arr = array(1, 2, 3, 4);
foreach ($arr as &$value) {
    $value = $value * 2;
}
unset($value);   // $value 不再引用 $arr[3]

　常見錯誤 #2： 誤解 isset() 的行為

　　儘管名字叫 isset，但是 isset() 不僅會在變數不存在的時候返回 false，在變數值為 null 的時候也會返回 false。

　　這種行為比最初出現的問題更為棘手，同時也是一種常見的錯誤源。

　　看看下面的程式碼： 

$data = fetchRecordFromStorage($storage, $identifier);
if (!isset($data['keyShouldBeSet']) {
    // do something here if 'keyShouldBeSet' is not set
}

　　開發者想必是想確認 keyShouldBeSet 是否存在於 $data 中。然而，正如上面說的，如果 $data['keyShouldBeSet'] 存在並且值為 null 的時候， isset($data['keyShouldBeSet']) 也會返回 false。所以上面的邏輯是不嚴謹的。

　　我們來看另外一個例子：

if ($_POST['active']) {
    $postData = extractSomething($_POST);
}

// ...

if (!isset($postData)) {
    echo 'post not active';
}

　　上述程式碼，通常認為，假如 $_POST['active'] 返回 true，那麼 postData 必將存在，因此 isset($postData) 也將返回 true。反之， isset($postData) 返回 false 的唯一可能是 $_POST['active'] 也返回 false。

　　然而事實並非如此！

　　如我所言，如果$postData 存在且被設定為 null， isset($postData) 也會返回 false 。 也就是說，即使 $_POST['active'] 返回 true， isset($postData) 也可能會返回 false 。 再一次說明上面的邏輯不嚴謹。

　　順便一提，如果上面程式碼的意圖真的是再次確認 $_POST['active'] 是否返回 true，依賴 isset() 來做，不管對於哪種場景來說都是一種糟糕的決定。更好的做法是再次檢查 $_POST['active']，即：

if ($_POST['active']) {
    $postData = extractSomething($_POST);
}

// ...

if ($_POST['active']) {
    echo 'post not active';
}

　　對於這種情況，雖然檢查一個變數是否真的存在很重要（即：區分一個變數是未被設定還是被設定為 null）；但是使用 array_key_exists() 這個函式卻是個更健壯的解決途徑。

　　比如，我們可以像下面這樣重寫上面第一個例子：

$data = fetchRecordFromStorage($storage, $identifier);
if (! array_key_exists('keyShouldBeSet', $data)) {
    // do this if 'keyShouldBeSet' isn't set
}

　　另外，通過結合 array_key_exists() 和 get_defined_vars()， 我們能更加可靠的判斷一個變數在當前作用域中是否存在： 

if (array_key_exists('varShouldBeSet', get_defined_vars())) {
    // variable $varShouldBeSet exists in current scope
}

　常見錯誤 #3：關於通過引用返回與通過值返回的困惑

　　考慮下面的程式碼片段：

class Config
{
    private $values = [];

    public function getValues() {
        return $this->values;
    }
}

$config = new Config();

$config->getValues()['test'] = 'test';
echo $config->getValues()['test'];

　　如果你執行上面的程式碼，將得到下面的輸出：

PHP Notice:  Undefined index: test in /path/to/my/script.php on line 21

　　出了什麼問題？

　　上面程式碼的問題在於沒有搞清楚通過引用與通過值返回陣列的區別。除非你明確告訴 PHP 通過引用返回一個陣列（例如，使用 &），否則 PHP 預設將會「通過值」返回這個陣列。這意味著這個陣列的一份拷貝將會被返回，因此被調函式與呼叫者所訪問的陣列並不是同樣的陣列例項。

　　所以上面對 getValues() 的呼叫將會返回 $values 陣列的一份拷貝，而不是對它的引用。考慮到這一點，讓我們重新回顧一下以上例子中的兩個關鍵行：

// getValues() 返回了一個 $values 陣列的拷貝
// 所以`test`元素被新增到了這個拷貝中，而不是 $values 陣列本身。
$config->getValues()['test'] = 'test';


// getValues() 又返回了另一份 $values 陣列的拷貝
// 且這份拷貝中並不包含一個`test`元素（這就是為什麼我們會得到 「未定義索引」 訊息）。
echo $config->getValues()['test'];

　　一個可能的修改方法是儲存第一次通過 getValues() 返回的 $values 陣列拷貝，然後後續操作都在那份拷貝上進行；例如：

$vals = $config->getValues();
$vals['test'] = 'test';
echo $vals['test'];

　　這段程式碼將會正常工作（例如，它將會輸出test而不會產生任何「未定義索引」訊息），但是這個方法可能並不能滿足你的需求。特別是上面的程式碼並不會修改原始的$values陣列。如果你想要修改原始的陣列（例如新增一個test元素），就需要修改getValues()函式，讓它返回一個$values陣列自身的引用。通過在函式名前面新增一個&來說明這個函式將返回一個引用；例如：

class Config
{
    private $values = [];

    // 返回一個 $values 陣列的引用
    public function &getValues() {
        return $this->values;
    }
}

$config = new Config();

$config->getValues()['test'] = 'test';
echo $config->getValues()['test'];

　　這會輸出期待的test。

　　但是現在讓事情更困惑一些，請考慮下面的程式碼片段：

class Config
{
    private $values;

    // 使用陣列物件而不是陣列
    public function __construct() {
        $this->values = new ArrayObject();
    }

    public function getValues() {
        return $this->values;
    }
}

$config = new Config();

$config->getValues()['test'] = 'test';
echo $config->getValues()['test'];

　　如果你認為這段程式碼會導致與之前的陣列例子一樣的「未定義索引」錯誤，那就錯了。實際上，這段程式碼將會正常執行。原因是，與陣列不同，PHP 永遠會將物件按引用傳遞。（ArrayObject 是一個 SPL 物件，它完全模仿陣列的用法，但是卻是以物件來工作。）

　　像以上例子說明的，你應該以引用還是拷貝來處理通常不是很明顯就能看出來。因此，理解這些預設的行為（例如，變數和陣列以值傳遞；物件以引用傳遞）並且仔細檢視你將要呼叫的函式 API 文件，看看它是返回一個值，陣列的拷貝，陣列的引用或是物件的引用是必要的。

　　儘管如此，我們要認識到應該儘量避免返回一個陣列或 ArrayObject，因為這會讓呼叫者能夠修改例項物件的私有資料。這就破壞了物件的封裝性。所以最好的方式是使用傳統的「getters」和「setters」，例如：

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');    // 輸出『testValue』

　　這個方法讓呼叫者可以在不對私有的$values陣列本身進行公開訪問的情況下設定或者獲取陣列中的任意值。

　常見的錯誤 #4：在迴圈中執行查詢

　　如果像這樣的話，一定不難見到你的 PHP 無法正常工作。

$models = [];

foreach ($inputValues as $inputValue) {
    $models[] = $valueRepository->findByValue($inputValue);
}

　　這裡也許沒有真正的錯誤， 但是如果你跟隨著程式碼的邏輯走下去， 你也許會發現這個看似無害的呼叫$valueRepository->findByValue() 最終執行了這樣一種查詢，例如：

$result = $connection->query("SELECT `x`,`y` FROM `values` WHERE `value`=" . $inputValue);

　　結果每輪迴圈都會產生一次對資料庫的查詢。 因此，假如你為這個迴圈提供了一個包含 1000 個值的陣列，它會對資源產生 1000 單獨的請求！如果這樣的指令碼在多個執行緒中被呼叫，他會有導致系統崩潰的潛在危險。

　　因此，至關重要的是，當你的程式碼要進行查詢時，應該儘可能的收集需要用到的值，然後在一個查詢中獲取所有結果。

　　一個我們平時常常能見到查詢效率低下的地方 （例如：在迴圈中）是使用一個陣列中的值 (比如說很多的 ID )向表發起請求。檢索每一個 ID 的所有的資料，程式碼將會迭代這個陣列，每個 ID 進行一次SQL查詢請求，它看起來常常是這樣：

$data = [];
foreach ($ids as $id) {
    $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` = " . $id);
    $data[] = $result->fetch_row();
}

　　但是 只用一條 SQL 查詢語句就可以更高效的完成相同的工作，比如像下面這樣：

$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: 記憶體使用欺騙與低效

　　一次取多條記錄肯定是比一條條的取高效，但是當我們使用 PHP 的 mysql 擴充套件的時候，這也可能成為一個導致 libmysqlclient 出現『記憶體不足』（out of memory）的條件。

　　我們在一個測試盒裡演示一下，該測試盒的環境是：有限的記憶體（512MB RAM），MySQL，和 php-cli。

　　我們將像下面這樣引導一個資料表：

// 連線 mysql
$connection = new mysqli('localhost', 'username', 'password', 'database');

// 建立 400 個欄位
$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);

// 寫入 2 百萬行資料
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);
}

　　OK，現在讓我們一起來看一下記憶體使用情況：

// 連線 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";

　　輸出結果是：

Before: 224704
Limit 1: 224704
Limit 10000: 224704

　　Cool。 看來就記憶體使用而言，內部安全地管理了這個查詢的記憶體。

　　為了更加明確這一點，我們把限制提高一倍，使其達到 100,000。 額~如果真這麼幹了，我們將會得到如下結果：

PHP Warning:  mysqli::query(): (HY000/2013):
              Lost connection to MySQL server during query in /root/test.php on line 11

　　究竟發生了啥？

　　這就涉及到 PHP 的 mysql 模組的工作方式的問題了。它其實只是個 libmysqlclient 的代理，專門負責幹髒活累活。每查出一部分資料後，它就立即把資料放入記憶體中。由於這塊記憶體還沒被 PHP 管理，所以，當我們在查詢裡增加限制的數量的時候， memory_get_peak_usage() 不會顯示任何增加的資源使用情況 。我們被『記憶體管理沒問題』這種自滿的思想所欺騙了，所以才會導致上面的演示出現那種問題。 老實說，我們的記憶體管理確實是有缺陷的，並且我們也會遇到如上所示的問題。

　　如果使用 mysqlnd 模組的話，你至少可以避免上面那種欺騙（儘管它自身並不會提升你的記憶體利用率）。 mysqlnd 被編譯成原生的 PHP 擴充套件，並且確實 會 使用 PHP 的記憶體管理器。

　　因此，如果使用 mysqlnd 而不是 mysql，我們將會得到更真實的記憶體利用率的資訊：

Before: 232048
Limit 1: 324952
Limit 10000: 32572912

　　順便一提，這比剛才更糟糕。根據 PHP 的文件所說，mysql 使用 mysqlnd 兩倍的記憶體來儲存資料， 所以，原來使用 mysql 那個指令碼真正使用的記憶體比這裡顯示的更多（大約是兩倍）。

　　為了避免出現這種問題，考慮限制一下你查詢的數量，使用一個較小的數字來迴圈，像這樣：

$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 結合起來考慮的時候， 就會意識到我們的程式碼理想需要在兩者間實現一個平衡。是讓查詢粒度化和重複化，還是讓單個查詢巨大化。生活亦是如此，平衡不可或缺；哪一個極端都不好，都可能會導致 PHP 無法正常執行。

　常見錯誤 #6: 忽略 Unicode/UTF-8 的問題

　　從某種意義上說，這實際上是PHP本身的一個問題，而不是你在除錯 PHP 時遇到的問題，但是它從未得到妥善的解決。 PHP 6 的核心就是要做到支援 Unicode。但是隨著 PHP 6 在 2010 年的暫停而擱置了。

　　這並不意味著開發者能夠避免 正確處理 UTF-8 並避免做出所有字串必須是『古老的 ASCII』的假設。 沒有正確處理非 ASCII 字串的程式碼會因為引入粗糙的 海森堡bug（heisenbugs）  而變得臭名昭著。當一個名字包含 『Schrödinger』的人註冊到你的系統時，即使簡單的 strlen($_POST['name']) 呼叫也會出現問題。

　　下面是一些可以避免出現這種問題的清單：

• 如果你對 UTF-8 還不瞭解，那麼你至少應該瞭解下基礎的東西。 這兒 有個很好的引子。
• 確保使用 mb_* 函式代替老舊的字串處理函式（需要先保證你的 PHP 構建版本開啟了『多位元組』（multibyte）擴充套件）。
• 確保你的資料庫和表設定了 Unicode 編碼（許多 MySQL 的構建版本仍然預設使用 latin1  ）。
• 記住 json_encode() 會轉換非 ASCII 標識（比如： 『Schrödinger』會被轉換成 『Schru00f6dinger』），但是 serialize() 不會 轉換。
• 確保 PHP 檔案也是 UTF-8 編碼，以避免在連線硬編碼字串或者配置字串常量的時候產生衝突。

　　Francisco Claria  在本部落格上發表的 UTF-8 Primer for PHP and MySQL  是份寶貴的資源。

　常見錯誤 #7: 認為 $_POST 總是包含你 POST 的資料

　　不管它的名稱，$_POST 陣列不是總是包含你 POST 的資料，他也有可能會是空的。 為了理解這一點，讓我們來看一下下面這個例子。假設我們使用 jQuery.ajax() 模擬一個服務請求，如下：

// js
$.ajax({
    url: 'http://my.site/some/path',
    method: 'post',
    data: JSON.stringify({a: 'a', b: 'b'}),
    contentType: 'application/json'
});

　　（順帶一提，注意這裡的 contentType: 'application/json' 。我們用 JSON 型別傳送資料，這在介面中非常流行。這在 AngularJS $http service 裡是預設的傳送資料的型別。）

　　在我們舉例子的服務端，我們簡單的列印一下 $_POST 陣列：

// php
var_dump($_POST);

　　奇怪的是，結果如下：

array(0) { }

　　為什麼？我們的 JSON 串 {a: 'a', b: 'b'} 究竟發生了什麼？

　　原因在於 當內容型別為 application/x-www-form-urlencoded 或者 multipart/form-data 的時候 PHP 只會自動解析一個 POST 的有效內容。這裡面有歷史的原因 --- 這兩種內容型別是在 PHP 的 $_POST 實現前就已經在使用了的兩個重要的型別。所以不管使用其他任何內容型別 （即使是那些現在很流行的，像 application/json）， PHP 也不會自動載入到 POST 的有效內容。

　　既然 $_POST 是一個超級全域性變數，如果我們重寫 一次 （在我們的指令碼里儘可能早的），被修改的值（包括 POST 的有效內容）將可以在我們的程式碼裡被引用。這很重要因為 $_POST 已經被 PHP 框架和幾乎所有的自定義的指令碼普遍使用來獲取和傳遞請求資料。

　　所以，舉個例子，當處理一個內容型別為 application/json 的 POST 有效內容的時候 ，我們需要手動解析請求內容（decode 出 JSON 資料）並且覆蓋 $_POST 變數，如下：

// php
$_POST = json_decode(file_get_contents('php://input'), true);

　　然後當我們列印 $_POST 陣列的時候，我們可以看到他正確的包含了 POST 的有效內容；如下：

array(2) { ["a"]=> string(1) "a" ["b"]=> string(1) "b" }

　常見錯誤 #8: 認為 PHP 支援單字元資料型別

　　閱讀下面的程式碼並思考會輸出什麼：

for ($c = 'a'; $c <= 'z'; $c++) {
    echo $c . "\n";
}

　　如果你的答案是 a 到 z，那麼你可能會對這是一個錯誤答案感到吃驚。

　　沒錯，它確實會輸出 a 到 z，但是，它還會繼續輸出 aa 到 yz。我們一起來看一下這是為什麼。

　　PHP 中沒有 char 資料型別； 只能用 string 型別。記住一點，在 PHP 中增加 string 型別的 z 得到的是 aa：

php> $c = 'z'; echo ++$c . "\n";
aa

　　沒那麼令人混淆的是，aa 的字典順序是 小於  z 的：

php> var_export((boolean)('aa' < 'z')) . "\n";
true

　　這也是為什麼上面那段簡單的程式碼會輸出 a 到 z， 然後 繼續 輸出 aa到 yz。 它停在了 za，那是它遇到的第一個比 z 大 的：

php> var_export((boolean)('za' < 'z')) . "\n";
false

　　事實上，在 PHP 裡 有合適的 方式在迴圈中輸出 a 到 z 的值：

for ($i = ord('a'); $i <= ord('z'); $i++) {
    echo chr($i) . "\n";
}

　　或者是這樣：

$letters = range('a', 'z');

for ($i = 0; $i < count($letters); $i++) {
    echo $letters[$i] . "\n";
}

　常見 錯誤 #9: 忽視程式碼規範

　　儘管忽視程式碼標準並不直接導致需要去除錯 PHP 程式碼，但這可能是所有需要談論的事情裡最重要的一項。

　　在一個專案中忽視程式碼規範能夠導致大量的問題。最樂觀的預計，前後程式碼不一致（在此之前每個開發者都在“做自己的事情”）。但最差的結果，PHP 程式碼不能執行或者很難（有時是不可能的）去順利通過，這對於 除錯程式碼、提升效能、維護專案來說也是困難重重。並且這意味著降低你們團隊的生產力，增加大量的額外（或者至少是本不必要的）精力消耗。

　　幸運的是對於 PHP 開發者來說，存在 PHP 編碼標準建議（PSR），它由下面的五個標準組成：

• PSR-0: 自動載入標準
• PSR-1: 基礎編碼標準
• PSR-2: 編碼風格指導
• PSR-3: 日誌介面
• PSR-4: 自動載入增強版

　　PSR 起初是由市場上最大的組織平臺維護者創造的。 Zend, Drupal, Symfony, Joomla 和 其他 為這些標準做出了貢獻，並一直遵守它們。甚至，多年前試圖成為一個標準的 PEAR ，現在也加入到 PSR 中來。

　　某種意義上，你的程式碼標準是什麼幾乎是不重要的，只要你遵循一個標準並堅持下去，但一般來講，跟隨 PSR 是一個很不錯的主意，除非你的專案上有其他讓人難以抗拒的理由。越來越多的團隊和專案正在遵從 PSR 。在這一點上，大部分的 PHP 開發者達成了共識，因此使用 PSR 程式碼標準，有利於使新加入團隊的開發者對你的程式碼標準感到更加的熟悉與舒適。

　常見錯誤 #10:  濫用 empty()

　　一些 PHP 開發者喜歡對幾乎所有的事情使用 empty() 做布林值檢驗。不過，在一些情況下，這會導致混亂。

　　首先，讓我們回到陣列和 ArrayObject 例項（和陣列類似）。考慮到他們的相似性，很容易假設它們的行為是相同的。然而，事實證明這是一個危險的假設。舉例，在 PHP 5.0 中:

// PHP 5.0 或後續版本:
$array = [];
var_dump(empty($array));        // 輸出 bool(true)
$array = new ArrayObject();
var_dump(empty($array));        // 輸出 bool(false)
// 為什麼這兩種方法不產生相同的輸出呢？

　　更糟糕的是，PHP 5.0之前的結果可能是不同的：

// PHP 5.0 之前:
$array = [];
var_dump(empty($array));        // 輸出 bool(false)
$array = new ArrayObject();
var_dump(empty($array));        // 輸出 bool(false)

　　這種方法上的不幸是十分普遍的。比如，在 Zend Framework 2 下的 Zend\Db\TableGateway 的 TableGateway::select() 結果中呼叫 current() 時返回資料的方式，正如文件所表明的那樣。開發者很容易就會變成此類資料錯誤的受害者。

　　為了避免這些問題的產生，更好的方法是使用 count() 去檢驗空陣列結構：

// 注意這會在 PHP 的所有版本中發揮作用 (5.0 前後都是):
$array = [];
var_dump(count($array));        // 輸出 int(0)
$array = new ArrayObject();
var_dump(count($array));        // 輸出 int(0)

　　順便說一句, 由於 PHP 將 0 轉換為 false , count() 能夠被使用在 if() 條件內部去檢驗空陣列。同樣值得注意的是，在 PHP 中， count() 在陣列中是常量複雜度 (O(1) 操作) ，這更清晰的表明它是正確的選擇。

　　另一個使用 empty() 產生危險的例子是當它和魔術方法 _get() 一起使用。我們來定義兩個類並使其都有一個 test 屬性。

　　首先我們定義包含 test 公共屬性的 Regular 類。

class Regular
{
    public $test = 'value';
}

　　然後我們定義 Magic 類，這裡使用魔術方法 __get() 來操作去訪問它的 test 屬性：

class Magic
{
    private $values = ['test' => 'value'];

    public function __get($key)
    {
        if (isset($this->values[$key])) {
            return $this->values[$key];
        }
    }
}

　　好了，現在我們嘗試去訪問每個類中的 test 屬性看看會發生什麼：

$regular = new Regular();
var_dump($regular->test);    // 輸出 string(4) "value"
$magic = new Magic();
var_dump($magic->test);      // 輸出 string(4) "value"

　　到目前為止還好。

　　但是現在當我們對其中的每一個都呼叫 empty() ，讓我們看看會發生什麼：

var_dump(empty($regular->test));    // 輸出 bool(false)
var_dump(empty($magic->test));      // 輸出 bool(true)

　　咳。所以如果我們依賴 empty() ,我們很可能誤認為 $magic 的屬性 test 是空的，而實際上它被設定為 'value'。

　　不幸的是，如果類使用魔術方法 __get() 來獲取屬性值，那麼就沒有萬無一失的方法來檢查該屬性值是否為空。

　　在類的作用域之外，你僅僅只能檢查是否將返回一個 null 值，這並不意味著沒有設定相應的鍵，因為它實際上還可能被設定為 null 。

　　相反，如果我們試圖去引用 Regular 類例項中不存在的屬性，我們將得到一個類似於以下內容的通知：

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() 方法應該被謹慎地使用，因為如果不小心的話它可能導致混亂 -- 甚至潛在的誤導 -- 結果。

　總結

　　PHP 的易用性讓開發者陷入一種虛假的舒適感，語言本身的一些細微差別和特質，可能花費掉你大量的時間去除錯。這些可能會導致 PHP 程式無法正常工作，並導致諸如此處所述的問題。

　　PHP 在其20年的歷史中，已經發生了顯著的變化。花時間去熟悉語言本身的微妙之處是值得的，因為它有助於確保你編寫的軟體更具可擴充套件性，健壯和可維護性。