準備好南瓜糖和蘋果酒了嗎？一年一度的萬聖節(jié)又到了！雖然全球各地慶祝萬聖節(jié)的狂熱程度不及美國，但我還是想分享一些“恐怖”的PHP技巧來慶祝這個節(jié)日。這篇文章輕鬆有趣，將向您展示PHP自身的一些令人驚訝（但合乎邏輯）的行為，以及一些人利用PHP完成任務時那些令人毛骨悚然（且可能非常不合邏輯）的方法。您可以把它看作我的節(jié)日禮物，一點程序員的“精神糖果”——畢竟，為什麼只有不給糖就搗蛋的小朋友才能享用所有美味呢？

要點總結

• PHP可能會表現(xiàn)出意想不到的行為，例如在第一個foreach循環(huán)之外保留引用，導致輸出結果出乎意料?？梢酝ㄟ^使用數(shù)組的鍵將字符串重新賦值來緩解這個問題。
• 當使用PHP執(zhí)行更複雜的任務（例如shell腳本）時，理解在fork時執(zhí)行環(huán)境是如何克隆的，以及各種資源如何在所有進程中受到影響至關重要。例如，連接數(shù)據(jù)庫時，最好在fork子進程後在父進程中連接，子進程如有需要則自行連接。
• 單例模式（實際上只不過是花哨的面向對象全局變量）會使調(diào)試變得困難。建議盡可能避免使用單例模式。
• 雖然像“Spooky Scary PHP”這樣的非常規(guī)編碼實踐很有趣且具有教育意義，但它們通常不被認為是編寫生產(chǎn)代碼的良好實踐，因為它們通常涉及使用效率低下、不清楚或不可預測的函數(shù)或技術。

鬧鬼的數(shù)組

從前，在一個不那麼遙遠的開發(fā)工作室裡，亞瑟深夜還在編寫代碼。他不知道自己即將使用的數(shù)組鬧鬼了！每敲擊一次鍵盤，他都感到一陣寒意從脊椎滑落，但他愚蠢地忽略了這種微妙的預感。

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

好吧，這個數(shù)組並沒有真正鬧鬼，但輸出結果確實出乎意料：

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

這種“恐怖”行為的原因在於PHP如何在第一個foreach循環(huán)之外保留引用。當?shù)诙€循環(huán)開始時，$word仍然是引用，指向數(shù)組的最後一個元素。第二個循環(huán)的第一次迭代將“double”賦值給$word，這覆蓋了最後一個元素。第二次迭代將“toil”賦值給$word，再次覆蓋最後一個元素。當循環(huán)讀取最後一個元素的值時，它已經(jīng)被多次覆蓋了。要深入了解這種行為，我建議閱讀Johannes Schlüter關於這個主題的博客文章，“References and foreach”。您還可以運行這個稍微修改過的版本並檢查其輸出，以便更好地了解PHP正在做什麼：

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

亞瑟那天晚上吸取了一個非常重要的教訓，並使用數(shù)組的鍵將字符串重新賦值來修復了他的代碼：

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

幽靈數(shù)據(jù)庫連接

PHP越來越多的被要求不僅僅是每天生成網(wǎng)頁。用PHP編寫的shell腳本數(shù)量正在增加，這些腳本執(zhí)行的任務也越來越複雜，因為開發(fā)人員看到了整合開發(fā)語言的優(yōu)點。通常情況下，這些腳本的性能是可以接受的，為了方便而進行的權衡是可以證明的。因此，蘇珊正在編寫一個並行處理任務，其代碼類似於以下代碼：

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
var_dump($spell);
foreach ($spell as $word) {
    echo join(" ", $spell) . "n";
}

她的代碼fork了子進程來並行執(zhí)行一些長時間運行的工作，而父進程繼續(xù)監(jiān)控子進程，並在所有子進程終止時報告結果。

<?php
foreach ($spell as $key => $word) {
    $spell[$key] = ucfirst($word);
}

然而，蘇珊的領導要求她將狀態(tài)信息記錄到日誌中，而不是輸出到標準輸出。蘇珊使用已經(jīng)包含在公司代碼庫中的單例模式PDO數(shù)據(jù)庫連接機制擴展了她的代碼。

#! /usr/bin/env php
<?php
$pids = array();
foreach (range(0, 4) as $i) {
    $pid = pcntl_fork();
    if ($pid > 0) {
        echo "Fork child $pid.n";
        // record PIDs in reverse lookup array
        $pids[$pid] = true;
    } else if ($pid == 0) {
        echo "Child " . posix_getpid() . " working...n";
        sleep(5);
        exit;
    }
}
// wait for children to finish
while (count($pids)) {
    $pid = pcntl_wait($status);
    echo "Child $pid finished.n";
    unset($pids[$pid]);
}
echo "Tasks complete.n";

蘇珊期望看到timings表中的行被更新；“start time”行應該列出整個進程啟動的時間戳，“stop time”行應該列出所有進程完成的時間戳。不幸的是，執(zhí)行拋出了異常，數(shù)據(jù)庫沒有反映她的預期。

<code>Fork child 1634.
Fork child 1635.
Fork child 1636.
Child 1634 working...
Fork child 1637.
Child 1635 working...
Child 1636 working...
Fork child 1638.
Child 1637 working...
Child 1638 working...
Child 1637 finished.
Child 1636 finished.
Child 1638 finished.
Child 1635 finished.
Child 1634 finished.
Tasks complete.</code>

#! /usr/bin/env php
<?php
$db = Db::connection();
$db->query("UPDATE timings SET tstamp=NOW() WHERE name='start time'");

$pids = array();
foreach (range(0, 4) as $i) {
    ...
}
while (count($pids)) {
    ...
}

$db->query("UPDATE timings SET tstamp=NOW() WHERE name='stop time'");

class Db
{
    protected static $db;

    public static function connection() {
        if (!isset(self::$db)) {
            self::$db = new PDO("mysql:host=localhost;dbname=test",
                "dbuser", "dbpass");
            self::$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        return self::$db;
    }
}

像亞瑟的數(shù)組一樣，蘇珊的數(shù)據(jù)庫也鬧鬼了嗎？好吧，如果我給你以下線索，看看你能不能把這個謎團拼湊起來：1. 當一個進程fork時，父進程會被複製為子進程。然後，這些複製的進程從那時起並行執(zhí)行。 2. 靜態(tài)成員在類的所有實例之間共享。

PDO連接被包裝為單例，因此應用程序中對它的任何引用都指向內(nèi)存中的相同資源。 DB::connection()首先返回對象引用，父進程fork，子進程繼續(xù)處理，而父進程等待，子進程終止並PHP清理使用的資源，然後父進程嘗試再次使用數(shù)據(jù)庫對象。連接到MySQL的連接已在子進程中關閉，因此最終調(diào)用失敗。在最終日誌記錄查詢之前天真地嘗試再次獲取連接不會幫助蘇珊，因為會返回相同的失效PDO實例，因為它是一個單例。我建議避免使用單例——它們實際上只不過是花哨的面向對象的全局變量，這會使調(diào)試變得困難。即使在我們的例子中，連接仍然會被子進程關閉，但如果在第二個查詢之前調(diào)用DB::connection()，如果不用單例，它至少會返回一個新的連接。但更好的方法是理解在fork時執(zhí)行環(huán)境是如何克隆的，以及各種資源如何在所有進程中受到影響。在這種情況下，最好在fork子進程後在父進程中連接到數(shù)據(jù)庫，子進程如有需要則自行連接。連接不應該共享。

<code>PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /home/susanbrown/test.php:21
Stack trace:
#0 /home/susanbrown/test.php(21): PDO->query('UPDATE timers S...')
#1 {main}</code>

弗蘭肯斯坦博士的API

瑪麗·雪萊的《弗蘭肯斯坦》講述的是一個科學家創(chuàng)造生命的故事，但他對其醜陋感到厭惡，於是拋棄了它。在一些不必要的死亡和破壞之後，弗蘭肯斯坦博士追捕他的創(chuàng)造物，直到世界的盡頭，試圖摧毀它。我們許多人都賦予瞭如此醜陋的代碼以生命，以至於我們後來希望自己能逃離它——代碼如此醜陋、如此愚鈍、如此混亂，以至於讓我們想嘔吐，但它只想要愛和理解。幾年前，我一直在玩弄一個關於數(shù)據(jù)庫接口的想法，以及如果它們更嚴格地遵守Unix的“一切都是文件”的哲學，它們會是什麼樣子：查詢將被寫入“文件”，結果集將從“文件”中讀取。一件事導致另一件事，經(jīng)過我自己的一些死亡和破壞性編碼之後，我編寫了以下這個與我最初的想法幾乎沒有關係的類：

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

結果是天才的，但令人厭惡：一個看起來像對象（沒有真正的API方法）、數(shù)組或字符串的實例……

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

我此後不久寫了一篇博客，並將其標記為邪惡的?？吹剿呐笥押屯聨缀醵甲龀隽送瑯拥姆磻骸疤袅?！現(xiàn)在把它殺了……用火燒死它?！?但多年以來，我承認我對它有所軟化。它真正違反的唯一規(guī)則是程序員對query()和result()等平淡無奇的命名方法的期望。相反，它使用查詢字符串本身作為查詢方法，對像是接口，結果集是結果。當然，它並不比過度泛化的ORM接口更糟糕，ORM接口將select()和where()方法鏈接在一起，看起來像SQL查詢，但有更多的->。也許我的類並沒有那麼邪惡？也許它只是想被愛？我當然不想死在北極！

結束語

我希望您喜歡這篇文章，並且這些例子不會給您帶來（太多）噩夢！我相信您也有自己關於鬧鬼或可怕代碼的故事，無論您身在何處，都不需要讓節(jié)日的樂趣消失，因此請隨時在下面的評論中分享您可怕的PHP故事！ 圖片來自Fotolia

(以下為FAQ，已根據(jù)原文內(nèi)容調(diào)整和精簡)

關於“Spooky Scary PHP”的常見問題

什麼是“Spooky Scary PHP”？

“Spooky Scary PHP”是一種獨特的PHP編碼方法，它涉及使用非常規(guī)或意想不到的方法來實現(xiàn)某些結果。這可能包括使用鮮為人知的函數(shù)、利用語言中的特性，甚至使用看起來不應該工作但確實有效的代碼。這是一種有趣且令人興奮的方式，可以探索PHP的深度，並且經(jīng)常會帶來令人驚訝和啟迪的發(fā)現(xiàn)。

如何開始學習“Spooky Scary PHP”？

學習“Spooky Scary PHP”的最佳方法是對PHP基礎知識有紮實的理解。一旦您對基礎知識感到滿意，就可以開始探索該語言更晦澀的角落。閱讀關於“Spooky Scary PHP”的文章、教程和論壇討論也可能非常有幫助。記住，目標不是編寫高效或實用的代碼，而是以更深入的方式探索和理解語言。

“Spooky Scary PHP”是一種好的實踐嗎？

“Spooky Scary PHP”通常不被認為是編寫生產(chǎn)代碼的良好實踐。它通常涉及使用效率低下、不清楚或不可預測的函數(shù)或技術。但是，它可能是學習更多關於該語言以及挑戰(zhàn)您對PHP的理解的一種好方法。它更像是一種學習工具和有趣的實驗，而不是一種實用的編碼風格。

“Spooky Scary PHP”有害嗎？

雖然“Spooky Scary PHP”既有趣又有教育意義，但務必負責任地使用它。在“Spooky Scary PHP”中使用的一些技術如果在實時環(huán)境中使用，可能會造成危害，例如那些利用語言中的特性或錯誤的技術。務必徹底測試您編寫的任何代碼，並且永遠不要在項目的重要部分使用“Spooky Scary PHP”技術。

以上是怪異的可怕php的詳細內(nèi)容。更多資訊請關注PHP中文網(wǎng)其他相關文章！