وقتی یک برنامه PHP اجرا نمی‌شود، نتیجه اشتباه تولید می‌کند یا در بخشی از برنامه رفتار غیرمنتظره‌ای دارد، اولین کاری که باید انجام دهیم پیدا کردن علت واقعی مشکل است. این فرآیند در برنامه‌نویسی Debugging یا دیباگ کردن نام دارد.
Debug کردن PHP فقط به این معنی نیست که خطاهای PHP را روی صفحه نمایش دهیم. در پروژه‌های واقعی، ممکن است برنامه هیچ خطای واضحی نمایش ندهد، اما خروجی اشتباه باشد، یک Query نتیجه مورد انتظار را برنگرداند، یک متغیر مقدار نادرست داشته باشد یا اجرای برنامه در یک نقطه خاص متوقف شود.
به همین دلیل، یک توسعه‌دهنده PHP باید بتواند با استفاده از ابزارهایی مانند:
error_reporting()display_errorserror_log()var_dump()print_r()debug_backtrace()- Logها
- Breakpoint
- Xdebug
- Debugger محیط توسعه
مسیر اجرای برنامه را بررسی و مشکل را پیدا کند.
در این مقاله از پایه با Debugging در PHP آشنا می‌شویم و سپس روش‌های حرفه‌ای‌تر خطایابی را بررسی می‌کنیم.
Debug کردن PHP چیست؟
Debug کردن PHP به فرآیند پیدا کردن، بررسی و رفع خطاها و رفتارهای غیرمنتظره در یک برنامه PHP گفته می‌شود.
فرض کنید این کد را داریم:
<?php
$price = 100000;
$quantity = 0;
$total = $price / $quantity;
echo $total;
برنامه در زمان اجرا با مشکل مواجه می‌شود، زیرا تقسیم بر صفر انجام شده است.
در این شرایط Debugging به ما کمک می‌کند بفهمیم:
- خطا در کجا اتفاق افتاده است؟
- مقدار متغیرها هنگام اجرای آن بخش چه بوده است؟
- چه مسیری باعث رسیدن برنامه به این نقطه شده است؟
- علت اصلی مشکل چیست؟
- چگونه باید آن را اصلاح کنیم؟
بنابراین Debugging یک فرآیند بررسی و تحلیل برنامه است، نه صرفاً نمایش Error.
# چرا Debugging در PHP اهمیت دارد؟
هرچه پروژه بزرگ‌تر شود، پیدا کردن خطا بدون ابزارهای مناسب دشوارتر می‌شود.
در یک فایل چند خطی ممکن است بتوانیم مشکل را با نگاه کردن به کد پیدا کنیم؛ اما در یک پروژه واقعی PHP ممکن است جریان اجرا چیزی شبیه این باشد:
Request
↓
Router
↓
Controller
↓
Service
↓
Repository
↓
Database
↓
Response
اگر خروجی نهایی اشتباه باشد، مشخص نیست مشکل دقیقاً در کدام قسمت اتفاق افتاده است.
ممکن است:
- ورودی اشتباه باشد.
- Controller داده اشتباه دریافت کند.
- Service منطق نادرستی داشته باشد.
- Repository Query اشتباهی اجرا کند.
- Database داده مورد انتظار را نداشته باشد.
- یک شرط اشتباه باشد.
- یک Exception مدیریت نشده باشد.
- یک API خارجی پاسخ نامعتبر بدهد.
Debugging به ما کمک می‌کند این مسیر را مرحله‌به‌مرحله بررسی کنیم.
# انواع مشکل در برنامه PHP
قبل از Debug کردن باید بدانیم با چه نوع مشکلی مواجه هستیم.
به طور کلی مشکلات را می‌توان به چند گروه تقسیم کرد.
۱. Syntax Error
این خطا زمانی اتفاق می‌افتد که ساختار Syntax کد PHP اشتباه باشد.
مثلاً:
<?php
$name = "Ali
echo $name;
در اینجا رشته بسته نشده است.
یا:
<?php
if ($age > 18) {
echo "Adult";
در این مثال ساختار بلاک کامل نشده است.
این نوع خطاها معمولاً خیلی سریع توسط PHP شناسایی می‌شوند.
# ۲. Runtime Error
Runtime Error هنگام اجرای برنامه اتفاق می‌افتد.
برای مثال:
<?php
$result = 10 / 0;
در اینجا برنامه هنگام اجرا با مشکل مواجه می‌شود.
# ۳. Logical Error
یکی از مهم‌ترین انواع خطاها، خطای منطقی است.
فرض کنید می‌خواهیم قیمت نهایی را محاسبه کنیم:
$price = 100;
$discount = 20;
$total = $price + $discount;
کد ممکن است از نظر Syntax کاملاً صحیح باشد، اما منطق برنامه اشتباه است.
احتمالاً باید داشته باشیم:
$total = $price - $discount;
این نوع خطاها معمولاً سخت‌تر از Syntax Error پیدا می‌شوند، زیرا PHP لزوماً هیچ Errorای نمایش نمی‌دهد.
# ۴. Warning و Notice
برخی مشکلات PHP به شکل Warning یا Notice گزارش می‌شوند.
برای مثال:
<?php
echo $username;
اگر متغیر تعریف نشده باشد، بسته به نسخه PHP و تنظیمات Error Reporting، ممکن است پیام خطا یا هشدار دریافت کنیم.
# ۵. Exception
Exceptionها نیز می‌توانند در زمان اجرای برنامه ایجاد شوند.
مثلاً:
<?php
try {
// عملیات
} catch (Throwable $e) {
echo $e->getMessage();
}
مدیریت Exception موضوع گسترده‌ای است و بهتر است برای آن از مقاله اختصاصی Exception در PHP نیز استفاده کنید.
# Error Reporting در PHP چیست؟
یکی از اولین ابزارهایی که هنگام Debug کردن PHP باید بشناسیم، error_reporting() است.
این تابع مشخص می‌کند PHP چه سطحی از خطاها را گزارش کند.
مثلاً:
error_reporting(E_ALL);
برای محیط توسعه می‌توانیم از:
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
استفاده کنیم.
یک نمونه کامل:
<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
echo $undefinedVariable;
با این تنظیمات، PHP اطلاعات بیشتری درباره مشکل در اختیار توسعه‌دهنده قرار می‌دهد.
# آیا display_errors را در Production فعال کنیم؟
خیر.
این نکته بسیار مهم است.
در محیط Development نمایش خطا روی صفحه می‌تواند مفید باشد؛ اما در Production نمایش مستقیم خطاها می‌تواند اطلاعات داخلی برنامه را افشا کند.
مثلاً یک Error ممکن است مسیر فایل را نشان دهد:
/var/www/example/app/Services/PaymentService.php
یا اطلاعات دیگری درباره:
- مسیرهای سرور
- Queryها
- نام فایل‌ها
- ساختار داخلی برنامه
- Stack Trace
- تنظیمات سیستم
نمایش دهد.
بنابراین در Production معمولاً بهتر است:
display_errors = Off
log_errors = On
باشد.
یعنی خطا ثبت شود، اما مستقیماً به کاربر نمایش داده نشود.
# PHP Error Log چیست؟
به جای نمایش خطا روی صفحه می‌توانیم آن را در Log ذخیره کنیم.
برای مثال:
error_log("Something went wrong");
این دستور یک پیام را در Error Log ثبت می‌کند.
این روش مخصوصاً در Production اهمیت زیادی دارد.
به جای اینکه کاربر چنین اطلاعاتی ببیند:
Fatal error...
کاربر می‌تواند یک پیام عمومی مانند:
خطایی رخ داده است. لطفاً دوباره تلاش کنید.
دریافت کند و توسعه‌دهنده جزئیات را از Log بررسی کند.
# استفاده از var_dump برای Debug کردن PHP
یکی از ساده‌ترین ابزارهای Debugging در PHP، تابع var_dump() است.
مثلاً:
$name = "Saeed";
$age = 30;
var_dump($name);
var_dump($age);
خروجی شامل اطلاعاتی درباره مقدار و نوع داده خواهد بود.
مثلاً برای یک عدد ممکن است چیزی مشابه این ببینیم:
int(30)
و برای رشته:
string(5) "Saeed"
این ویژگی باعث می‌شود var_dump() برای بررسی نوع داده نیز بسیار مفید باشد.
# تفاوت var_dump و print_r
تابع:
print_r()
برای مشاهده ساختار Arrayها و Objectها بسیار کاربردی است.
مثلاً:
$user = [
'name' => 'Ali',
'email' => 'ali@example.com',
'age' => 25
];
print_r($user);
در مقابل:
var_dump($user);
اطلاعات دقیق‌تری درباره نوع و اندازه داده نمایش می‌دهد.
به صورت ساده:
| ابزار | کاربرد |
|---|---|
var_dump() | بررسی نوع و مقدار داده |
print_r() | مشاهده ساختار Array و Object |
error_log() | ثبت اطلاعات در Log |
| Xdebug | Debug حرفه‌ای و Step-by-Step |
# Debug کردن چند متغیر به صورت همزمان
گاهی می‌خواهیم چند مقدار را بررسی کنیم:
var_dump($user, $orders, $total);
این روش در Debug سریع بسیار مفید است.
اما نباید این دستورات را بدون بررسی از کد Production حذف‌نشده باقی بگذاریم.
# استفاده از die و exit هنگام Debug
گاهی می‌خواهیم اجرای برنامه را در یک نقطه متوقف کنیم.
می‌توانیم بنویسیم:
var_dump($user);
die();
یا:
print_r($data);
exit;
در این حالت ابتدا داده نمایش داده شده و سپس اجرای برنامه متوقف می‌شود.
مثلاً:
$user = getUser();
var_dump($user);
die();
sendEmail($user);
در این مثال sendEmail() دیگر اجرا نمی‌شود.
این روش برای Debug سریع مفید است، اما در پروژه‌های بزرگ بهتر است از Debugger حرفه‌ای استفاده شود.
# Debug کردن مقدار متغیرها
یکی از رایج‌ترین مشکلات PHP این است که یک متغیر مقدار مورد انتظار را ندارد.
مثلاً:
$total = $price * $quantity;
اگر خروجی اشتباه باشد، می‌توانیم بررسی کنیم:
var_dump($price);
var_dump($quantity);
var_dump($total);
به این ترتیب می‌توانیم بفهمیم مشکل از کدام مقدار شروع شده است.
# Debug کردن شرط‌ها
فرض کنید:
if ($user->is_admin) {
showAdminPanel();
}
اما پنل نمایش داده نمی‌شود.
قبل از شرط می‌توانیم مقدار را بررسی کنیم:
var_dump($user->is_admin);
اگر نتیجه مثلاً:
bool(false)
باشد، مشخص می‌شود شرط به دلیل مقدار false اجرا نشده است.
# Debug کردن Array
برای Arrayها می‌توانیم از:
print_r($data);
یا:
var_dump($data);
استفاده کنیم.
مثلاً:
$data = [
'name' => 'Ali',
'age' => 25,
'roles' => [
'admin',
'editor'
]
];
print_r($data);
با این کار می‌توانیم ساختار داده را بررسی کنیم.
# Debug کردن Object
برای Objectها نیز:
var_dump($user);
می‌تواند اطلاعات مفیدی ارائه کند.
مثلاً اگر انتظار داریم $user یک Object باشد اما مقدار آن null است، مشکل احتمالاً در مرحله قبل از آن قرار دارد.
# Debug کردن جریان اجرای برنامه
گاهی مقدار متغیرها درست است اما نمی‌دانیم کدام قسمت از کد اجرا شده است.
برای بررسی سریع می‌توانیم از پیام‌های Debug استفاده کنیم:
echo "Step 1";
$data = getData();
echo "Step 2";
$result = process($data);
echo "Step 3";
اگر فقط این خروجی را ببینیم:
Step 1
Step 2
متوجه می‌شویم مشکل بین Step 2 و Step 3 اتفاق افتاده است.
البته در پروژه واقعی بهتر است به جای echo از Log یا Debugger استفاده کنیم.
# debug_backtrace در PHP چیست؟
تابع debug_backtrace() یکی از ابزارهای کاربردی PHP برای بررسی مسیر اجرای توابع است.
مثلاً:
function test()
{
print_r(debug_backtrace());
}
function first()
{
test();
}
first();
در این حالت می‌توانیم اطلاعاتی درباره مسیر فراخوانی تابع دریافت کنیم.
یعنی بفهمیم:
first()
↓
test()
چه مسیری را طی کرده است.
در پروژه‌های پیچیده این اطلاعات می‌تواند برای پیدا کردن منشأ یک فراخوانی بسیار مفید باشد.
# Stack Trace چیست؟
وقتی یک Exception یا Error اتفاق می‌افتد، ممکن است PHP اطلاعاتی درباره مسیر اجرای برنامه ارائه کند.
این مسیر را معمولاً Stack Trace می‌نامیم.
برای مثال:
Controller
↓
Service
↓
Repository
↓
Database
اگر خطا در Repository رخ داده باشد، Stack Trace می‌تواند نشان دهد که چه تابعی آن را فراخوانی کرده است.
Stack Trace یکی از مهم‌ترین ابزارهای پیدا کردن ریشه خطا است.
# چگونه یک خطا را مرحله‌به‌مرحله پیدا کنیم؟
به جای اینکه تصادفی قسمت‌های مختلف کد را تغییر دهیم، بهتر است یک فرآیند مشخص داشته باشیم.
مرحله اول: مشکل را دقیق تعریف کنید
مثلاً نگویید:
> سایت خراب است.
بلکه مشخص کنید:
> هنگام ثبت سفارش، بعد از کلیک روی پرداخت، صفحه سفید نمایش داده می‌شود.
مرحله دوم: خطا را بازتولید کنید
باید بتوانید مشکل را دوباره ایجاد کنید.
مثلاً:
ورود
↓
افزودن محصول
↓
سبد خرید
↓
Checkout
↓
پرداخت
↓
خطا
هرچه فرآیند بازتولید دقیق‌تر باشد، Debugging ساده‌تر می‌شود.
مرحله سوم: Error Log را بررسی کنید
اگر Error یا Exception ثبت شده باشد، ابتدا Log را بررسی کنید.
مرحله چهارم: آخرین نقطه سالم را پیدا کنید
فرض کنید این مراحل داریم:
A → B → C → D → E
و می‌دانیم:
A → B → C
صحیح است اما:
D
مشکل دارد.
بنابراین به جای بررسی کل پروژه، روی مسیر:
C → D
تمرکز می‌کنیم.
مرحله پنجم: داده‌های ورودی را بررسی کنید
مثلاً:
var_dump($requestData);
یا در پروژه واقعی از Log استفاده کنید.
مرحله ششم: فرضیه بسازید
مثلاً:
> احتمالاً مقدار user_id خالی است.
سپس بررسی کنیم:
var_dump($user_id);
اگر فرضیه درست نبود، سراغ فرضیه بعدی برویم.
این روش بسیار بهتر از تغییر تصادفی کد است.
# Xdebug چیست؟
وقتی پروژه‌ها بزرگ‌تر می‌شوند، استفاده از:
var_dump()
و:
print_r()
دیگر همیشه کافی نیست.
در این شرایط یکی از مهم‌ترین ابزارهای Debugging در PHP یعنی Xdebug وارد می‌شود.
Xdebug یک Extension برای PHP است که قابلیت‌های پیشرفته‌ای مانند:
- Breakpoint
- Step Debugging
- مشاهده مقدار متغیرها
- Call Stack
- Stack Trace
- Profiling
- بررسی اجرای برنامه
را در اختیار توسعه‌دهنده قرار می‌دهد.
# Breakpoint چیست؟
Breakpoint یکی از مهم‌ترین مفاهیم Debugging حرفه‌ای است.
فرض کنید:
$user = getUser($id);
$order = createOrder($user);
saveOrder($order);
می‌توانیم روی خط:
$order = createOrder($user);
Breakpoint قرار دهیم.
وقتی برنامه به این خط برسد، اجرای آن متوقف می‌شود.
حالا می‌توانیم مقدار:
$user
را بررسی کنیم و ببینیم آیا داده‌ای که وارد تابع می‌شود صحیح است یا خیر.
# Step Over چیست؟
وقتی Debugger روی یک خط متوقف شده است، معمولاً می‌توانیم اجرای برنامه را خط‌به‌خط ادامه دهیم.
Step Over باعث می‌شود خط فعلی اجرا شود و Debugger به خط بعدی برود.
مثلاً:
$user = getUser($id);
$order = createOrder($user);
saveOrder($order);
Debugger می‌تواند این خطوط را یکی‌یکی اجرا کند.
# Step Into چیست؟
فرض کنید داریم:
$order = createOrder($user);
با Step Into می‌توانیم وارد تابع:
createOrder()
شویم و کد داخلی آن را نیز بررسی کنیم.
این قابلیت زمانی بسیار مفید است که مشکل درون یک تابع یا Service خاص قرار داشته باشد.
# Step Out چیست؟
اگر داخل یک تابع قرار گرفته‌ایم و متوجه شدیم مشکل در آنجا نیست، می‌توانیم از تابع خارج شویم و به محل فراخوانی قبلی برگردیم.
این کار با Step Out انجام می‌شود.
# Debugging در VS Code
اگر از VS Code برای توسعه PHP استفاده می‌کنید، می‌توانید محیط توسعه خود را برای Xdebug و Step Debugging تنظیم کنید.
ساختار کلی به این شکل است:
VS Code
↓
PHP
↓
Xdebug
↓
Debugger
در این حالت می‌توانید:
- Breakpoint قرار دهید.
- اجرای برنامه را متوقف کنید.
- مقدار متغیرها را ببینید.
- وارد تابع شوید.
- از تابع خارج شوید.
- Call Stack را بررسی کنید.
این روش نسبت به قرار دادن تعداد زیادی var_dump() در پروژه بسیار حرفه‌ای‌تر است.
# Debugging در PhpStorm
PhpStorm نیز ابزارهای Debugging بسیار کاملی برای PHP دارد.
با اتصال Xdebug به PhpStorm می‌توانید:
- Breakpoint تعریف کنید.
- Variables را مشاهده کنید.
- Call Stack را ببینید.
- Step Over انجام دهید.
- Step Into انجام دهید.
- Step Out انجام دهید.
- Watch Expression تعریف کنید.
برای پروژه‌های بزرگ PHP، استفاده از Debugger در IDE می‌تواند سرعت پیدا کردن خطا را به شکل قابل توجهی افزایش دهد.
# Debug کردن PHP در پروژه‌های واقعی
در پروژه‌های واقعی معمولاً یک خطا فقط در یک فایل قرار ندارد.
فرض کنید یک سیستم فروشگاهی داریم:
User
↓
Controller
↓
OrderService
↓
PaymentService
↓
Database
کاربر می‌گوید:
> پرداخت انجام نمی‌شود.
نباید بلافاصله PaymentService را تغییر دهیم.
ابتدا باید بررسی کنیم:
آیا Request دریافت شده؟
↓
آیا User معتبر است؟
↓
آیا Order ساخته شده؟
↓
آیا مبلغ صحیح است؟
↓
آیا PaymentService فراخوانی شده؟
↓
آیا API درگاه پاسخ داده؟
↓
آیا پاسخ درست پردازش شده؟
این دقیقاً همان چیزی است که Debugging حرفه‌ای را از Debugging تصادفی جدا می‌کند.
# Debug کردن API در PHP
در APIها ممکن است مشکل از Request یا Response باشد.
مثلاً:
$data = json_decode(file_get_contents('php://input'), true);
var_dump($data);
می‌توانیم بررسی کنیم آیا JSON مورد انتظار دریافت شده است یا خیر.
مثلاً انتظار داریم:
{
"name": "Ali",
"email": "ali@example.com"
}
اما ممکن است:
$data
مقدار null داشته باشد.
در این شرایط باید بررسی کنیم:
- آیا Body ارسال شده؟
- آیا JSON معتبر است؟
- آیا Header مناسب ارسال شده؟
- آیا Content-Type صحیح است؟
- آیا Endpoint درست است؟
# Debug کردن Queryهای Database
گاهی مشکل ظاهراً مربوط به PHP است اما در واقع Query دیتابیس اشتباه است.
مثلاً:
$stmt = $pdo->prepare(
"SELECT * FROM users WHERE email = ?"
);
$stmt->execute([$email]);
اگر نتیجه‌ای دریافت نمی‌کنیم، باید بررسی کنیم:
var_dump($email);
و همچنین Query، پارامترها و داده موجود در Database را بررسی کنیم.
در پروژه‌های واقعی بهتر است Queryها و اطلاعات Debug حساس را به شکل امن در Log ثبت کنیم.
# Debug کردن Composer و Autoload
اگر با خطایی مانند:
Class "App\Services\UserService" not found
مواجه شدید، ممکن است مشکل از:
- Namespace
- نام Class
- مسیر فایل
- PSR-4
- Composer Autoload
باشد.
در چنین شرایطی بررسی ساختار پروژه و سپس اجرای:
composer dump-autoload
می‌تواند یکی از مراحل Debugging باشد.
البته باید ابتدا علت مشکل را مشخص کنیم و صرفاً اجرای این دستور را راه‌حل همه خطاهای Autoload ندانیم.
# Debug کردن خطای Class Not Found
فرض کنید داریم:
use App\Services\UserService;
$userService = new UserService();
اما PHP می‌گوید:
Class "App\Services\UserService" not found
باید بررسی کنیم:
- فایل وجود دارد؟
- Namespace صحیح است؟
- نام Class صحیح است؟
- نام فایل صحیح است؟
- مسیر PSR-4 صحیح است؟
- Composer Autoload به‌روز است؟
مثلاً فایل:
app/Services/UserService.php
باید Namespace متناسبی داشته باشد:
namespace App\Services;
# Debug کردن Environment Variables
یکی از خطاهای رایج پروژه‌های PHP مربوط به Configuration است.
مثلاً:
$apiKey = getenv('API_KEY');
اگر مقدار دریافت نشود، ممکن است:
var_dump($apiKey);
مقدار مورد انتظار را نشان ندهد.
در چنین شرایطی باید:
- نام متغیر را بررسی کنید.
- فایل Configuration را بررسی کنید.
- محیط اجرای برنامه را بررسی کنید.
- Cache تنظیمات را در صورت استفاده از Framework بررسی کنید.
نکته مهم این است که Secretها و API Keyها را در Log یا خروجی صفحه چاپ نکنید.
# Debug کردن مشکلات Session
فرض کنید کاربر Login می‌کند اما بلافاصله Logout می‌شود.
می‌توانیم بررسی کنیم:
var_dump($_SESSION);
اما در پروژه واقعی باید مواردی مانند:
- Session Cookie
- Session ID
- Domain
- Path
- HTTPS
- تنظیمات Session
- ذخیره‌سازی Session
نیز بررسی شوند.
اگر Session در سمت سرور وجود داشته باشد اما Browser Cookie را ارسال نکند، رفتار برنامه می‌تواند غیرمنتظره شود.
# Debug کردن Cookie
برای بررسی Cookieها می‌توانیم:
var_dump($_COOKIE);
را بررسی کنیم.
اما اگر Cookie مورد انتظار وجود ندارد، باید مواردی مانند:
Domain
Path
Secure
HttpOnly
SameSite
Expiration
را نیز بررسی کنیم.
# Debug کردن درخواست HTTP
اگر PHP با یک API خارجی ارتباط دارد، ممکن است مشکل از درخواست HTTP باشد.
در این شرایط فقط Response را بررسی نکنید.
باید در صورت امکان بررسی شود:
URL
Method
Headers
Body
Authentication
Status Code
Response Body
Timeout
مثلاً اگر API پاسخ:
401 Unauthorized
برگرداند، احتمالاً مشکل مربوط به Authentication است.
اگر:
404 Not Found
باشد، باید Endpoint را بررسی کنیم.
اگر:
500 Internal Server Error
باشد، ممکن است مشکل در سمت سرویس مقصد باشد.
# Debug کردن بدون نمایش اطلاعات حساس
یکی از اشتباهات رایج این است که توسعه‌دهنده برای Debug کردن همه چیز را چاپ می‌کند:
var_dump($_SERVER);
var_dump($_SESSION);
var_dump($_COOKIE);
var_dump($_POST);
این کار می‌تواند اطلاعات حساسی مانند:
- Cookie
- Session
- Token
- Authorization Header
- اطلاعات کاربر
- مسیرهای داخلی
را افشا کند.
بنابراین Debugging باید همیشه با در نظر گرفتن امنیت انجام شود.
# Debug در Development و Production چه تفاوتی دارد؟
یکی از مهم‌ترین اصول Debugging این است که محیط توسعه و Production را از هم جدا کنیم.
Development
در Development می‌توانیم:
display_errors = On
داشته باشیم و از ابزارهایی مانند:
Xdebug
var_dump
Debugger
Detailed Logs
استفاده کنیم.
Production
در Production بهتر است:
display_errors = Off
log_errors = On
باشد.
کاربر باید پیام عمومی دریافت کند و جزئیات خطا در Log ذخیره شود.
# آیا هر خطایی باید با Debugging حل شود؟
خیر.
گاهی مشکل از کد نیست.
ممکن است مشکل از:
- Server
- PHP Version
- Extension
- Database
- Network
- DNS
- File Permission
- Configuration
- External API
- Web Server
باشد.
مثلاً اگر کدی در PHP 8.3 به خوبی اجرا می‌شود اما روی یک سرور با نسخه یا Extension متفاوت مشکل دارد، باید محیط اجرا را نیز بررسی کنیم.
# Debug کردن PHP در Laravel
اگرچه Laravel یک Framework مستقل است، اصول Debugging PHP در آن نیز کاربرد دارند.
برای مثال در Laravel می‌توانیم از ابزارهای مختلفی برای بررسی داده‌ها و Logها استفاده کنیم.
برای Debug سریع، روش‌هایی مانند:
dd($user);
بسیار رایج هستند.
dd() مخفف مفهوم Dump and Die است؛ یعنی داده را نمایش می‌دهد و اجرای برنامه را متوقف می‌کند.
مثلاً:
public function show($id)
{
$user = User::find($id);
dd($user);
return view('users.show', compact('user'));
}
برای Debug حرفه‌ای پروژه‌های Laravel نیز می‌توان از Logها، Debugger و ابزارهای مناسب توسعه استفاده کرد.
اگر با Laravel کار می‌کنید، بهتر است مقاله مرتبط با Exception در PHP و همچنین مقالات Laravel سایت را نیز در کنار این مقاله مطالعه کنید.
# تفاوت Debugging و Error Handling
این دو مفهوم یکی نیستند.
Error Handling
یعنی برنامه بداند در صورت وقوع خطا چه رفتاری داشته باشد.
مثلاً:
try {
processPayment();
} catch (Throwable $e) {
logError($e);
return 'Payment failed';
}
Debugging
یعنی توسعه‌دهنده بفهمد چرا خطا اتفاق افتاده است.
پس:
Error Handling
↓
مدیریت خطا
Debugging
↓
پیدا کردن علت خطا
هر دو برای ساخت نرم‌افزار قابل اعتماد مهم هستند.
# Debugging و Logging چه تفاوتی دارند؟
Logging یعنی ثبت اطلاعات مربوط به اجرای برنامه.
مثلاً:
error_log("Payment request started");
Debugging فرآیند تحلیل این اطلاعات و سایر شواهد برای پیدا کردن مشکل است.
می‌توان این رابطه را این‌گونه در نظر گرفت:
Application
↓
Logs
↓
Evidence
↓
Debugging
↓
Root Cause
↓
Fix
# Root Cause چیست؟
یکی از مهم‌ترین مفاهیم در Debugging، پیدا کردن Root Cause یا علت اصلی مشکل است.
فرض کنید کاربر می‌گوید:
> صفحه پرداخت باز نمی‌شود.
ممکن است چندین علامت ببینیم:
Payment Page Error
↓
PaymentService Error
↓
Missing API Key
در اینجا:
Payment Page Error
علامت است.
اما:
Missing API Key
ممکن است علت اصلی باشد.
توسعه‌دهنده حرفه‌ای نباید فقط اولین Error را برطرف کند؛ باید تا حد امکان به علت اصلی برسد.
# روش علمی Debug کردن PHP
برای Debugging حرفه‌ای می‌توان از این فرآیند استفاده کرد:
1. مشاهده مشکل
↓
2. بازتولید مشکل
↓
3. جمع‌آوری اطلاعات
↓
4. بررسی Log
↓
5. محدود کردن محدوده مشکل
↓
6. بررسی ورودی‌ها
↓
7. بررسی جریان اجرا
↓
8. پیدا کردن Root Cause
↓
9. اصلاح
↓
10. تست مجدد
این فرآیند باعث می‌شود Debugging از یک کار تصادفی به یک فرآیند سیستماتیک تبدیل شود.
# اشتباهات رایج هنگام Debug کردن PHP
۱. استفاده بیش از حد از var_dump
var_dump() ابزار خوبی است اما نباید تنها ابزار Debugging شما باشد.
۲. تغییر چند قسمت کد به صورت همزمان
اگر پنج قسمت کد را همزمان تغییر دهید و مشکل حل شود، مشخص نیست دقیقاً کدام تغییر باعث حل مشکل شده است.
بهتر است تغییرات کنترل‌شده باشند.
۳. نادیده گرفتن Log
گاهی پاسخ واقعی مشکل در Log وجود دارد اما توسعه‌دهنده فقط صفحه مرورگر را بررسی می‌کند.
۴. Debug کردن بدون بازتولید مشکل
اگر ندانیم مشکل دقیقاً چگونه اتفاق می‌افتد، پیدا کردن علت بسیار دشوارتر می‌شود.
۵. نمایش Errorهای Production به کاربر
این کار هم از نظر امنیتی خطرناک است و هم تجربه کاربری مناسبی ایجاد نمی‌کند.
۶. چاپ Secretها
نباید API Key، Password، Token یا Session اطلاعات حساس را برای Debug در خروجی چاپ کنیم.
۷. نادیده گرفتن Environment
گاهی کد صحیح است اما:
PHP Version
Extension
Configuration
Database
Server
متفاوت است.
# چک‌لیست Debug کردن PHP
وقتی با یک مشکل در PHP مواجه شدید، این چک‌لیست می‌تواند کمک کند:
بررسی اولیه
- [ ] مشکل را دقیق تعریف کرده‌ام.
- [ ] می‌توانم مشکل را دوباره ایجاد کنم.
- [ ] خطا را از Warning یا Notice تشخیص داده‌ام.
- [ ] Error Log را بررسی کرده‌ام.
- [ ] Stack Trace را بررسی کرده‌ام.
بررسی کد
- [ ] ورودی‌ها را بررسی کرده‌ام.
- [ ] مقدار متغیرها را بررسی کرده‌ام.
- [ ] شرط‌ها را بررسی کرده‌ام.
- [ ] مسیر اجرای برنامه را بررسی کرده‌ام.
- [ ] Return Value توابع را بررسی کرده‌ام.
بررسی محیط
- [ ] نسخه PHP را بررسی کرده‌ام.
- [ ] Extensionهای مورد نیاز فعال هستند.
- [ ] Configuration صحیح است.
- [ ] Database در دسترس است.
- [ ] Permissionها صحیح هستند.
- [ ] APIهای خارجی در دسترس هستند.
Debug حرفه‌ای
- [ ] در صورت نیاز Xdebug را فعال کرده‌ام.
- [ ] Breakpoint گذاشته‌ام.
- [ ] Call Stack را بررسی کرده‌ام.
- [ ] متغیرها را هنگام اجرای برنامه بررسی کرده‌ام.
- [ ] Root Cause را پیدا کرده‌ام.
# بهترین ابزارهای Debug کردن PHP
بسته به اندازه پروژه، ابزارهای مختلفی می‌توانند استفاده شوند.
| ابزار | کاربرد |
|---|---|
var_dump() | بررسی سریع مقدار و نوع داده |
print_r() | بررسی Array و Object |
error_log() | ثبت اطلاعات در Log |
debug_backtrace() | بررسی مسیر فراخوانی |
| PHP Error Log | بررسی خطاهای Runtime |
| Xdebug | Debug حرفه‌ای |
| VS Code | محیط توسعه و Debugging |
| PhpStorm | IDE حرفه‌ای PHP |
| Stack Trace | پیدا کردن مسیر اجرای خطا |
| Breakpoint | توقف اجرای برنامه در نقطه مشخص |
# آیا Debugging فقط برای پیدا کردن Error است؟
خیر.
این یکی از مهم‌ترین نکات این مقاله است.
ممکن است برنامه هیچ Errorای نداشته باشد اما رفتار اشتباهی داشته باشد.
مثلاً:
$total = $price + $discount;
از نظر Syntax صحیح است.
PHP ممکن است هیچ خطایی گزارش نکند.
اما اگر هدف ما محاسبه قیمت پس از تخفیف باشد، منطق برنامه اشتباه است.
بنابراین Debugging می‌تواند برای بررسی موارد زیر نیز استفاده شود:
- خروجی اشتباه
- داده اشتباه
- شرط اشتباه
- Query اشتباه
- جریان اجرای اشتباه
- API Response اشتباه
- وضعیت Session اشتباه
- محاسبات اشتباه
# جمع‌بندی
Debug کردن PHP یکی از مهارت‌های مهم هر توسعه‌دهنده PHP است. در پروژه‌های کوچک می‌توان با ابزارهایی مانند var_dump()، print_r() و error_log() مشکلات را بررسی کرد، اما در پروژه‌های بزرگ‌تر بهتر است از Logهای ساختاریافته، Stack Trace و Debuggerهایی مانند Xdebug استفاده شود.
مهم‌ترین نکته این است که Debugging را صرفاً به نمایش Error محدود نکنیم.
یک فرآیند مناسب Debugging معمولاً به شکل زیر است:
مشاهده مشکل
↓
بازسازی مشکل
↓
بررسی Error و Log
↓
بررسی ورودی‌ها
↓
بررسی جریان اجرای برنامه
↓
محدود کردن محدوده مشکل
↓
پیدا کردن Root Cause
↓
اصلاح
↓
تست مجدد
همچنین باید بین Development و Production تفاوت قائل شویم. نمایش جزئیات خطا در محیط توسعه می‌تواند بسیار مفید باشد، اما در Production بهتر است جزئیات خطا در Log ثبت شوند و اطلاعات داخلی برنامه به کاربر نمایش داده نشود.
در نهایت، اگر می‌خواهید در Debugging حرفه‌ای PHP مهارت پیدا کنید، مسیر مناسب این است که ابتدا ابزارهای پایه مانند var_dump() و error_log() را یاد بگیرید، سپس با Stack Trace و Logging کار کنید و در مرحله بعد سراغ Xdebug، Breakpoint و Step Debugging بروید.
سوالات متداول
Debug کردن PHP چیست؟
Debug کردن PHP فرآیند پیدا کردن، بررسی و رفع خطاها و رفتارهای غیرمنتظره در برنامه PHP است.
بهترین روش Debug کردن PHP چیست؟
برای مشکلات ساده، var_dump()، print_r() و Logها کاربردی هستند. برای پروژه‌های بزرگ‌تر، استفاده از Xdebug و Debugger محیط توسعه امکان بررسی مرحله‌به‌مرحله اجرای برنامه را فراهم می‌کند.
Xdebug در PHP چیست؟
Xdebug یک Extension برای PHP است که امکاناتی مانند Breakpoint، Step Debugging، بررسی Variables، Call Stack و Profiling را فراهم می‌کند.
تفاوت Error Handling و Debugging چیست؟
Error Handling به نحوه مدیریت خطا در زمان اجرای برنامه مربوط است، در حالی که Debugging فرآیند پیدا کردن علت خطا یا رفتار نادرست برنامه است.
آیا نمایش خطاهای PHP در Production مناسب است؟
به طور معمول نباید جزئیات خطاهای PHP به کاربران Production نمایش داده شود. بهتر است خطاها در Log ثبت شوند و کاربر یک پیام عمومی دریافت کند.
var_dump در PHP برای چیست؟
var_dump() برای بررسی مقدار، نوع و ساختار داده‌ها در PHP استفاده می‌شود و یکی از ابزارهای ساده Debugging است.
debug_backtrace در PHP چیست؟
debug_backtrace() اطلاعات مربوط به مسیر فراخوانی توابع را در اختیار توسعه‌دهنده قرار می‌دهد و برای بررسی Call Stack و پیدا کردن منشأ یک فراخوانی کاربرد دارد.
