ホームページ >バックエンド開発 >PHPチュートリアル >include_once および require_once_PHP チュートリアルには近づかないでください。
include_once の代わりに include を使用してみてください。その理由は、include_once はロードされたファイルのリストをクエリして存在するかどうかを確認し、それを再度ロードする必要があるためです。
確かにこの理由は正しいのですが、今日話したいのは別の理由ですファイルがロードされているかどうかを判断するには、PHP がファイルの open_path を取得する必要があることがわかっています。これは、たとえば次のことを意味します。
set_include_path("/tmp/:/tmp2/"); include_once("2.php");
?>
PHP が include_once "2.php" を認識すると、そうします。このファイルの実際のパスが分からず、ロードされたファイルのリストからロードされたかどうかを判断できないため、include_once の実装では、最初にこのファイルの実際のパスを解析しようとします (通常のファイルの場合、これは解析は getcwd とファイル パスの確認と同様なので、相対パスの場合は通常は成功しません) 解析が成功した場合、EG (include_files) が存在する場合は、それが含まれていることを意味します。それ以外の場合は、ファイルを開いて、このファイルのopened_pathを取得します。たとえば、上記の例では、このファイルは「/tmp2/2.php」に存在します。
次に、opened_pathを取得した後、PHPはロードされたファイルのリストを調べて、それが含まれているかどうかを確認し、含まれていない場合は直接コンパイルします。ファイルを開く必要はありません。
1. ファイルの絶対パスを解析して、解析が成功したかどうかを確認します。 EG (include_files)、存在する場合は戻り、存在しない場合は続行します
2. ファイルを開いてファイルのオープン パス (opened path) を取得します
3. EG (include_files) への開いたパスを取得して、存在する場合は返します。ただし、問題は、APC を使用する場合です...
APC を使用すると、APC はコンパイル済みファイルへのcompile_file ポインターをハイジャックするため、コンパイル結果をキャッシュから直接取得し、実際のファイルを開くためのシステムコールを回避します
ただし、コード内で include_once を使用すると、compile_file の前に、PHP はすでにファイルを開こうとしており、その後、APC によってハイジャックされたコンパイルファイルを入力します。この問題を解決するために、APC は include_once_override を導入しました。 include_once_override がオンになっている場合、APC は PHP の ZEND_INCLUDE_OR_EVAL オペコード ハンドラーをハイジャックし、ファイルが存在しないことが判明した場合にそのファイルの絶対パスを決定します。
のような未定義の問題がいくつか発生します。 set_include_path("/tmp");
function a($arg = array()) {
include_once("b.php");
}
a();
a();
?>
次に、私たちのb.phpは「/tmp/b.php」に配置されており、コンテンツは次のとおりです。b.phpのエラーは次のとおりです。これらの技術的要因を考慮すると、私は include_once の代わりに include を使用するべきだと常に考えてきました。なぜなら、ファイルは自分で完全に計画できるからです。ロードされるのは 1 回のみです。 include_once を使用すると、これを実行することもできます。コードに自信がないことを証明するだけです
したがって、include_once はもう使用しないことをお勧めします
http://www.bkjia.com/PHPjc/440397.html
www.bkjia.com
本当
http://www.bkjia.com/PHPjc/440397.html
技術記事
include_once の代わりに include を使用してみてください。その理由は、include_once がロードされたファイルのリストをクエリして、ロードする前にファイルが存在するかどうかを確認する必要があるからです。