MENU
contact

PHPのデバッグの出力について

PHP

採用はこちら

PHPのデバッグ出力とは、プログラムの実行中に変数の中身やエラー内容、処理の流れなどを確認するために、情報を画面やログに表示することです。

たとえば、次のような内容を確認したいときに使います。

  • 変数に想定どおりの値が入っているか
  • 配列やオブジェクトの中身がどうなっているか
  • 条件分岐が正しく通っているか
  • エラーや警告が発生していないか
  • SQLやAPIのレスポンスが正しいか

PHPでは、echo、var_dump()、print_r()、error_log()などを使ってデバッグ出力を行うことができます。

ただし、デバッグ出力は開発中には便利ですが、本番環境でそのまま表示すると、ファイルパス、SQL、個人情報、APIキーなどが外部に見えてしまう危険があります。

そのため、開発環境と本番環境で使い方を分けることが大切です。

目次

PHPでよく使うデバッグ出力の方法

echoで単純な値を確認する

echoは、文字列や数値などの単純な値を画面に出力するときに使います。

$name = 'Taro';

echo $name;

この場合、画面には次のように表示されます。

Taro

echoは、変数に文字列や数値が入っているかを軽く確認したいときに便利です。

$count = 10;

echo $count;

ただし、配列やオブジェクトの中身を確認する用途には向いていません。

$user = ['name' => 'Taro', 'age' => 25];

echo $user;

配列をそのままechoしても、配列の中身は表示されません。

多くの場合、Arrayと表示されたり、Array to string conversionの警告が出たりします。

そのため、配列やオブジェクトを確認したい場合は、print_r()やvar_dump()を使います。

var_dump()で型と値を詳しく確認する

var_dump()の基本

PHPのデバッグでよく使われるのがvar_dump()です。

var_dump()は、変数の値だけでなく、型や文字列の長さ、配列の要素数なども表示してくれます。

$user = [
    'name' => 'Taro',
    'age' => 25,
    'is_admin' => false
];

var_dump($user);

出力例は次のようになります。

array(3) {
  ["name"]=>
  string(4) "Taro"
  ["age"]=>
  int(25)
  ["is_admin"]=>
  bool(false)
}

var_dump()を使うと、string、int、bool、arrayなどの型まで確認できます。

型の違いを確認できる

PHPでは、見た目が同じでも型が違うことがあります。

$id1 = 1;
$id2 = '1';

var_dump($id1);
var_dump($id2);

出力例は次のとおりです。

int(1)
string(1) "1"

どちらも見た目は1ですが、$id1は整数、$id2は文字列です。

PHPでは型の違いが原因で、条件分岐や比較処理が意図しない動きになることがあります。

そのため、単に値を見るだけでなく、型まで確認したい場合はvar_dump()が便利です。

print_r()で配列やオブジェクトを見やすく確認する

print_r()の基本

print_r()は、配列やオブジェクトの中身を人間が読みやすい形で表示する関数です。

$user = [
    'name' => 'Taro',
    'age' => 25
];

print_r($user);

出力例は次のようになります。

Array
(
    [name] => Taro
    [age] => 25
)

var_dump()よりも表示がシンプルなので、配列の全体像をざっくり確認したいときに向いています。

print_r()は型の確認には弱い

print_r()は見やすい一方で、型の違いを細かく確認する用途にはあまり向いていません。

たとえば、次のような値があります。

$value1 = false;
$value2 = '';
$value3 = null;

print_r($value1);
print_r($value2);
print_r($value3);

false、空文字、nullなどは、画面上では何も表示されていないように見えることがあります。

このような値を正確に確認したい場合は、var_dump()を使う方が安全です。

var_dump($value1);
var_dump($value2);
var_dump($value3);

var_dump()とprint_r()の違い

詳細に確認するならvar_dump()

var_dump()は、値だけでなく型や文字列長なども表示します。

そのため、次のような場面に向いています。

  • 型の違いを確認したいとき
  • true、false、null、空文字を区別したいとき
  • 配列やオブジェクトの構造を詳しく見たいとき
  • バグの原因を細かく追いたいとき

見やすさを優先するならprint_r()

print_r()は、型の情報は少ないものの、配列やオブジェクトを見やすく表示できます。

そのため、次のような場面に向いています。

  • 配列の中身をざっくり確認したいとき
  • データ全体の構造を見たいとき
  • 表示をシンプルにしたいとき

実務では、まずprint_r()で全体を確認し、型や細かい違いが気になる場合にvar_dump()を使うと分かりやすいです。

ブラウザで見やすく表示する方法

preタグで囲む

ブラウザ上でvar_dump()やprint_r()をそのまま表示すると、改行やインデントが崩れて読みにくくなることがあります。

その場合は、<pre>タグで囲むと見やすくなります。

echo '<pre>';
var_dump($user);
echo '</pre>';

print_r()の場合も同じです。

echo '<pre>';
print_r($user);
echo '</pre>';

<pre>タグを使うことで、改行やスペースが保たれ、配列やオブジェクトの階層構造を確認しやすくなります。

ユーザー入力を表示する場合はエスケープも検討する

デバッグ出力であっても、ユーザー入力を含む値をHTML上に表示する場合は注意が必要です。

たとえば、入力値にHTMLタグやJavaScriptが含まれていると、ブラウザ上でそのまま解釈される可能性があります。

より安全に表示したい場合は、htmlspecialchars()を使います。

echo '<pre>';
echo htmlspecialchars(print_r($data, true), ENT_QUOTES, 'UTF-8');
echo '</pre>';

開発中の簡易確認では<pre>だけでも便利ですが、ユーザー入力を扱う場合は、セキュリティ面も意識しておくと安心です。

処理が通っているか確認するデバッグ出力

文字列を出して処理の通過点を確認する

変数の中身ではなく、「この処理が実行されているか」を確認したい場合もあります。

そのようなときは、簡単な文字列を出力します。

echo 'ここまで来た';

複数の場所に出力を入れる場合は、番号を付けると分かりやすくなります。

echo 'debug 1';

if ($user) {
    echo 'debug 2';
}

echo 'debug 3';

このようにすると、どこまで処理が進んでいるか、どの条件分岐を通っているかを確認できます。

APIやリダイレクト処理では画面出力に注意する

ただし、echoやvar_dump()で画面に出力すると、処理に影響することがあります。

たとえば、リダイレクト前に出力すると、header()が正しく動かない場合があります。

echo 'debug';

header('Location: /thanks.php');
exit;

また、JSONを返すAPIの途中でvar_dump()を出すと、JSON形式が壊れてしまいます。

var_dump($data);

echo json_encode($response);

このような処理では、画面出力ではなくerror_log()を使ってログに出す方が安全です。

exitやdieで処理を止めて確認する

exitで途中停止する

デバッグ中に、特定の場所で処理を止めて値を確認したい場合は、exitを使います。

$user = [
    'name' => 'Taro',
    'age' => 25
];

var_dump($user);
exit;

exitを書いた場所でPHPの処理が停止します。

dieも同じように使える

dieもexitとほぼ同じように使えます。

var_dump($user);
die;

値を表示して、その場で処理を止めたいときに便利です。

ただし、exitやdieは処理を強制終了するため、後続の処理が実行されなくなります。

ログ保存、セッション処理、レスポンス生成などに影響する場合もあります。

開発中には便利ですが、本番コードに残さないよう注意が必要です。

error_log()でログに出力する

error_log()の基本

画面に出さず、サーバーのログにデバッグ情報を出したい場合はerror_log()を使います。

error_log('デバッグメッセージ');

変数の値をログに出すこともできます。

$name = 'Taro';

error_log($name);

配列やオブジェクトをログに出す

配列やオブジェクトをそのままerror_log()に渡しても、期待どおりに中身を確認できないことがあります。

その場合は、print_r()の第2引数にtrueを指定して、文字列として取得します。

$user = [
    'name' => 'Taro',
    'age' => 25
];

error_log(print_r($user, true));

print_r($user, true)とすることで、画面には出力せず、結果を文字列として返すことができます。

var_dump()の結果をログに出す

var_dump()は直接文字列として返す関数ではないため、ログに出す場合は出力バッファリングを使います。

ob_start();
var_dump($user);
$result = ob_get_clean();

error_log($result);

これにより、var_dump()の出力内容を文字列として取得し、error_log()でログに記録できます。

error_log()の保存先は環境によって異なる

error_log()の出力先は、サーバー環境やPHPの設定によって異なります。

たとえば、次のような場所に記録されることがあります。

  • PHPのエラーログ
  • Apacheのエラーログ
  • Nginxのエラーログ
  • PHP-FPMのログ
  • レンタルサーバーの管理画面
  • Dockerコンテナのログ

ログが見つからない場合は、php.iniのerror_log設定や、Webサーバー側のログ設定を確認します。

エラー表示を有効にする方法

開発環境でエラーを表示する

PHPでは、エラーが発生していても設定によって画面に表示されないことがあります。

開発環境では、次のようにしてエラーを表示させることがあります。

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

error_reporting(E_ALL)は、可能な限り多くのエラーや警告を報告するための設定です。

開発中はエラーを見える状態にしておくことで、原因を早く見つけやすくなります。

ini_set()では反映されないエラーもある

ただし、ini_set()による設定は、PHPコードが実行された後に有効になります。

そのため、構文エラーのように、そもそもPHPファイルが正しく読み込まれないエラーには効かない場合があります。

たとえば、ファイル内に致命的な構文ミスがある場合、そのファイル内のini_set()まで処理が到達しません。

その場合は、次のような場所で設定する必要があります。

  • php.ini
  • .htaccess
  • Webサーバー設定
  • PHP-FPM設定
  • Dockerやローカル開発環境の設定ファイル

コード内のini_set()だけに頼らず、環境側の設定も確認することが大切です。

本番環境でのエラー表示設定

本番環境では画面にエラーを表示しない

本番環境では、エラー内容を画面に表示しないのが基本です。

本番環境でエラーを画面に出すと、次のような情報が外部に見えてしまう可能性があります。

  • サーバー内のファイルパス
  • データベース情報
  • SQL文
  • クラス名や関数名
  • 環境変数
  • APIキー
  • 個人情報
  • セッション情報

そのため、本番環境では次のように設定します。

ini_set('display_errors', '0');
ini_set('display_startup_errors', '0');
ini_set('log_errors', '1');
error_reporting(E_ALL);

画面には表示せず、ログに記録して確認する形が安全です。

display_startup_errorsも本番では基本的にOFFにする

display_startup_errorsは、PHPの起動時に発生したエラーを表示する設定です。

開発中は原因調査に役立ちますが、本番環境で有効にすると内部情報が表示される可能性があります。

そのため、本番環境ではdisplay_errorsだけでなく、display_startup_errorsも無効にしておくのが基本です。

var_export()でPHPコードに近い形で確認する

var_export()の基本

var_export()は、変数の内容をPHPコードとして扱いやすい形で出力する関数です。

$user = [
    'name' => 'Taro',
    'age' => 25
];

var_export($user);

出力例は次のようになります。

array (
  'name' => 'Taro',
  'age' => 25,
)

print_r()よりもPHPコードに近い形式で表示されるため、設定配列や一時的なデータ確認に便利です。

var_export()が向いている場面

var_export()は、次のような場面で役立ちます。

  • 配列をPHPコード風に確認したいとき
  • 設定値を一時的に書き出したいとき
  • デバッグ結果をコードに貼り付けたいとき
  • print_r()よりも厳密な形式で確認したいとき

ただし、大きな配列や複雑なオブジェクトでは出力が長くなるため、必要に応じて使い分けましょう。

JSON形式でデバッグ出力する

json_encode()で確認する

API開発やJavaScriptとの連携では、データをJSON形式で確認したいことがあります。

その場合は、json_encode()を使います。

$user = [
    'name' => 'Taro',
    'age' => 25
];

echo json_encode($user, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);

出力例は次のようになります。

{
    "name": "Taro",
    "age": 25
}

JSON_PRETTY_PRINTを使うと、整形された読みやすいJSONになります。

日本語を見やすくする

日本語を含むデータを確認する場合は、JSON_UNESCAPED_UNICODEを指定すると読みやすくなります。

$data = [
    'message' => 'こんにちは',
    'status' => 'success'
];

echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);

出力例です。

{
    "message": "こんにちは",
    "status": "success"
}

JSON_UNESCAPED_UNICODEを付けない場合、日本語がUnicodeエスケープされて読みにくくなることがあります。

APIレスポンスではContent-Typeも意識する

APIとしてJSONを返す場合は、必要に応じてヘッダーも指定します。

header('Content-Type: application/json; charset=UTF-8');

echo json_encode($data, JSON_UNESCAPED_UNICODE);

ただし、APIレスポンスの途中でvar_dump()やechoを使うと、JSON形式が壊れてしまいます。

APIのデバッグでは、画面出力よりもerror_log()を使う方が安全です。

自作のデバッグ関数を作る

debug()関数を作る

毎回<pre>やvar_dump()を書くのが面倒な場合は、デバッグ用の関数を作ると便利です。

function debug($value)
{
    echo '<pre>';
    var_dump($value);
    echo '</pre>';
}

使うときは次のようにします。

debug($user);

これで、値を見やすい形で確認できます。

dd()関数を作る

表示したあとに処理を止めたい場合は、dd()のような関数を作ることもできます。

function dd($value)
{
    echo '<pre>';
    var_dump($value);
    echo '</pre>';
    exit;
}

使い方は次のとおりです。

dd($user);

ddは「dump and die」の略として使われることが多く、値を表示して処理を停止するデバッグ方法です。

開発環境だけで動かす工夫をする

自作のデバッグ関数を作る場合は、本番環境で動かないようにしておくと安全です。

function debug($value)
{
    if (getenv('APP_ENV') !== 'local') {
        return;
    }

    echo '<pre>';
    var_dump($value);
    echo '</pre>';
}

このように、環境変数などで開発環境かどうかを判定してから出力します。

ただし、LaravelやSymfonyなどのフレームワークを使っている場合は、フレームワーク側の環境判定機能を使う方が実務的です。

debug_backtrace()で呼び出し元を確認する

debug_backtrace()とは

debug_backtrace()は、現在の処理がどの関数やファイルから呼び出されたのかを確認できる関数です。

関数の呼び出し関係を調べたいときに役立ちます。

function test()
{
    $trace = debug_backtrace();

    echo '<pre>';
    print_r($trace);
    echo '</pre>';
}

test();

debug_print_backtrace()も使える

より簡単に呼び出し履歴を表示したい場合は、debug_print_backtrace()も使えます。

function test()
{
    debug_print_backtrace();
}

test();

関数がどこから呼ばれているのか分からない場合や、処理の流れを追いたい場合に便利です。

ただし、出力にはファイルパスや関数名などの内部情報が含まれます。本番環境で画面に表示するのは避けましょう。

SQLのデバッグ出力

SQL文を確認する

PHPでデータベースを扱う場合、実行しようとしているSQL文を確認したいことがあります。

$sql = 'SELECT * FROM users WHERE id = :id';

error_log($sql);

SQL文をログに出すことで、意図したクエリになっているか確認できます。

バインド値も確認する

PDOなどでプレースホルダを使っている場合は、SQL文だけでなくバインド値も確認すると原因を特定しやすくなります。

$params = [
    ':id' => 1
];

error_log(print_r($params, true));

プリペアドステートメントでは、SQL文と値が別々に扱われるため、SQL本文とバインド値を分けて確認するのが現実的です。

本番環境でSQLログを出す場合の注意点

SQLやバインド値には、個人情報や機密情報が含まれることがあります。

たとえば、次のような情報です。

  • 氏名
  • メールアドレス
  • 電話番号
  • 住所
  • パスワードハッシュ
  • 認証トークン
  • 注文情報
  • 決済関連情報

本番環境でログに出す場合は、必要最小限にし、機密情報をマスキングすることが重要です。

APIレスポンスのデバッグ出力

APIレスポンスを確認する

外部APIと連携している場合は、APIから返ってきたレスポンスを確認することがあります。

$response = file_get_contents('https://example.com/api');

echo '<pre>';
print_r($response);
echo '</pre>';

JSON形式のレスポンスであれば、json_decode()して配列として確認すると見やすくなります。

$data = json_decode($response, true);

echo '<pre>';
print_r($data);
echo '</pre>';

APIデバッグで確認すべきポイント

API連携で不具合が起きた場合は、次のような情報を確認すると原因を特定しやすくなります。

  • HTTPステータスコード
  • レスポンス本文
  • リクエストURL
  • 送信パラメータ
  • リクエストヘッダー
  • レスポンスヘッダー
  • 認証トークンの有効期限
  • JSONのパースエラー

ただし、APIキーやアクセストークンをそのまま画面やログに出すのは危険です。

必要に応じて一部を伏せるようにしましょう。

Laravelでのデバッグ出力

dump()とdd()を使う

Laravelでは、dump()やdd()を使って簡単にデバッグできます。

dump($user);

dump()は値を表示しますが、処理はそのまま続行されます。

dd($user);

dd()は値を表示したあと、処理を停止します。

開発中に変数の中身を確認したいときに非常に便利です。

ログに出力する

Laravelで画面に出さずログに記録したい場合は、次のようにします。

\Log::debug($user);

または、logger()も使えます。

logger($user);

ログに出力すれば、画面表示を崩さずにデバッグできます。

本番環境ではAPP_DEBUGをfalseにする

Laravelの本番環境では、.envのAPP_DEBUGを必ずfalseにします。

APP_DEBUG=false

APP_DEBUG=trueのまま本番公開すると、詳細なエラー画面が表示され、ファイルパスや環境情報などが外部に見えてしまう可能性があります。

また、ログレベルの設定によってはdebugレベルのログが記録されない場合があります。

LOG_LEVEL=debug

デバッグログを確認したい場合は、ログレベルの設定も見直しましょう。

WordPressでのデバッグ出力

wp-config.phpでデバッグを有効にする

WordPressでは、wp-config.phpに設定を追加してデバッグを有効にできます。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

それぞれの意味は次のとおりです。

設定内容
WP_DEBUGWordPressのデバッグモードを有効にする
WP_DEBUG_LOGエラーをログファイルに記録する
WP_DEBUG_DISPLAYエラーを画面に表示するかどうかを制御する
display_errorsPHPのエラー画面表示を制御する

WP_DEBUG_LOGを使うには、基本的にWP_DEBUGを有効にする必要があります。

debug.logに記録する

WP_DEBUG_LOGを有効にすると、通常は次のファイルにログが記録されます。

wp-content/debug.log

画面にエラーを表示せず、ログで確認したい場合は、WP_DEBUG_DISPLAYをfalseにします。

define('WP_DEBUG_DISPLAY', false);

debug.logの公開に注意する

wp-content/debug.logには、エラー内容やファイルパス、場合によっては個人情報が記録されることがあります。

そのため、debug.logがWebから直接閲覧できる状態になっていると危険です。

WordPressでデバッグログを使う場合は、ログファイルが外部から見られないように、サーバー設定やセキュリティ設定も確認しましょう。

Xdebugを使った本格的なデバッグ

Xdebugとは

Xdebugは、PHP開発を支援する拡張機能です。

var_dump()やprint_r()のように値を画面に出すだけでなく、エディタと連携して本格的なデバッグができます。

Xdebugでできること

Xdebugを使うと、次のようなことができます。

機能内容
ブレークポイント指定した行で処理を一時停止する
ステップ実行1行ずつ処理を確認する
変数確認実行中の変数の中身を見る
コールスタック確認どの関数から呼ばれたか確認する
例外の追跡エラーや例外の発生箇所を調べる
プロファイリング処理速度やボトルネックを調べる

小規模な確認であればvar_dump()やprint_r()で十分ですが、複雑なアプリケーションではXdebugを使うと効率的です。

Xdebugは開発環境で使う

Xdebugは便利ですが、常時有効にするとパフォーマンスに影響することがあります。

そのため、基本的にはローカル開発環境や検証環境で使い、本番環境では無効にしておくのが一般的です。

PHPのデバッグ出力でよくあるミス

本番環境にvar_dump()を残してしまう

よくあるミスが、本番環境にvar_dump()やprint_r()を残してしまうことです。

var_dump($user);

これが本番環境に残っていると、ユーザーに内部情報が見えてしまう可能性があります。

特に、次のような情報を出力すると危険です。

情報リスク
$_SESSIONセッション情報の漏えい
$_COOKIE認証情報の漏えい
$_SERVERサーバー情報やパス情報の漏えい
データベース接続情報不正アクセスの手がかりになる
APIキー外部サービスを悪用される可能性がある
SQLエラーデータベース構造を推測される可能性がある
個人情報情報漏えいにつながる

デバッグ出力は、開発が終わったら削除するか、開発環境でのみ動くようにしましょう。

配列をechoしてしまう

配列をそのままechoしても、中身は確認できません。

echo $array;

配列を確認したい場合は、次のようにします。

print_r($array);

または、

var_dump($array);

JSONレスポンスを壊してしまう

API開発では、途中でvar_dump()やechoを入れると、JSONレスポンスが壊れることがあります。

var_dump($data);

echo json_encode($response);

この場合、フロントエンド側でJSONパースエラーになる可能性があります。

APIのデバッグでは、画面に出力するのではなく、error_log()を使う方が安全です。

ログに機密情報を出してしまう

ログは画面に表示されないため安全に見えますが、機密情報をそのまま出すのは危険です。

特に、次のような情報はログに出さないか、マスキングする必要があります。

  • パスワード
  • APIキー
  • アクセストークン
  • クレジットカード情報
  • 個人情報
  • セッションID
  • Cookie
  • 認証ヘッダー

たとえば、不要な情報を削除してからログに出します。

$user = [
    'name' => 'Taro',
    'email' => 'taro@example.com',
    'password' => 'secret'
];

unset($user['password']);

error_log(print_r($user, true));

ログは開発者にとって便利ですが、管理方法を誤ると情報漏えいの原因になります。

実務でおすすめの使い分け

目的別の使い分け

PHPのデバッグ出力は、目的に応じて使い分けると効率的です。

目的おすすめの方法
文字列や数値を軽く確認したいecho
配列を見やすく確認したいprint_r()
型まで詳しく確認したいvar_dump()
PHPコードに近い形で確認したいvar_export()
JSON形式で確認したいjson_encode()
画面に出さず確認したいerror_log()
処理を止めて確認したいvar_dump() + exit
呼び出し元を確認したいdebug_backtrace()
本格的に調査したいXdebug
Laravelで確認したいdump() / dd() / Log::debug()
WordPressで確認したいWP_DEBUG_LOG

開発環境と本番環境で分ける

開発環境では、エラーを画面に表示して原因をすぐ確認できるようにします。

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

一方、本番環境では、エラーを画面に表示せず、ログに記録します。

ini_set('display_errors', '0');
ini_set('display_startup_errors', '0');
ini_set('log_errors', '1');
error_reporting(E_ALL);

本番環境では、ユーザーにエラー内容を見せないことが重要です。

PHPのデバッグ出力を安全に使うポイント

本番環境では画面に出さない

本番環境でvar_dump()やprint_r()を表示すると、内部情報が漏れる可能性があります。

デバッグ情報は、開発環境だけで表示するようにしましょう。

ログには必要な情報だけを出す

ログに何でも出すと、あとから確認しにくくなるだけでなく、機密情報が残るリスクもあります。

ログには、原因調査に必要な情報だけを出すことが大切です。

個人情報や認証情報はマスクする

メールアドレス、電話番号、トークン、パスワードなどは、そのままログに出さないようにします。

必要な場合は、一部を伏せて記録します。

デバッグコードは消し忘れない

開発中に入れたvar_dump()、print_r()、exit、dieなどは、作業後に必ず確認して削除しましょう。

特にexitやdieが残っていると、本番環境で処理が途中で止まる原因になります。

まとめ

PHPのデバッグ出力は、プログラムの不具合を調べるうえで欠かせない基本的な方法です。

単純な値を確認するならecho、配列を見やすく確認するならprint_r()、型まで詳しく確認するならvar_dump()が便利です。

また、画面に出さずに確認したい場合はerror_log()を使います。

APIやリダイレクト処理では、画面出力によってレスポンスが壊れることがあるため、ログ出力を使う方が安全です。

開発環境では、display_errorsやerror_reporting(E_ALL)を使ってエラーを見える状態にすると原因を特定しやすくなります。

一方、本番環境では、エラーを画面に表示せず、ログに記録する設定にすることが重要です。

特に注意すべきなのは、本番環境にデバッグ出力を残さないことです。

var_dump()やprint_r()には、ファイルパス、SQL、セッション情報、APIキー、個人情報などが含まれる可能性があります。

PHPのデバッグ出力は、正しく使えば非常に便利ですが、使い方を誤ると情報漏えいや不具合の原因になります。

開発環境と本番環境を明確に分け、安全に扱うことが大切です。

以上、PHPのデバッグの出力についてでした。

最後までお読みいただき、ありがとうございました。

PHP
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

  1. ホーム
  2. PHP
  3. PHPのデバッグの出力について
目次