誠然, 這個理由是對的, 不過, 我今天要說的, 是另外一個的原因.
我們知道, PHP去判斷一個文件是否被加載, 是需要得到這個文件的opened_path的, 意思是說, 比如:

復制代碼 代碼如下:

    <?php
    set_include_path("/tmp/:/tmp2/");
    include_once("2.php");
    ?>

1. 嘗試解析文件的絕對路徑, 如果能解析成功, 則檢查EG(included_files), 存在則返回, 不存在繼續
2. 打開文件, 得到文件的打開路徑(opened path)
3. 拿opened path去EG(included_files)查找, 是否存在, 如果存在則返回, 不存在繼續
4. 編譯文件(compile_file)

這個在大多數情況下, 不是問題, 然而問題出在當你使用APC的時候…

在使用APC的時候, APC劫持了compile_file這個編譯文件的指針, 從而直接從cache中得到編譯結果, 避免了對實際文件的open, 避免了對open的system call.

然而, 當你在代碼中使用include_once的時候, 在compile_file之前, PHP已經嘗試去open file了, 然后才進入被APC劫持的compile file中, 這樣一來, 就會產生一次額外的open操作. 而APC正是為了解決這個問題, 引入了include_once_override, 在include_once_override開啟的情況下, APC會劫持PHP的ZEND_INCLUDE_OR_EVAL opcode handler, 通過stat來確定文件的絕對路徑, 然后如果發現沒有被加載, 就改寫opcode為include, 做一個tricky解決方案.

但是, 很可惜, 如我所說, APC的include_once_override實現的一直不好, 會有一些未定義的問題, 比如:

復制代碼 代碼如下:

    <?php
    set_include_path("/tmp");
    function a($arg = array()) {
        include_once("b.php");
    }

    a();
    a();
    ?>

復制代碼 代碼如下:

    <?php
      class B {}
    ?>

排除這些技術因素, 我也一直認為, 我們應該使用include, 而不是include_once, 因為我們完全能做到自己規劃, 一個文件只被加載一次. 還可以借助自動加載, 來做到這一點.

你使用include_once,只能證明, 你對自己的代碼沒信心.
所以, 建議大家, 不要再使用include_once