Debug در Laravel چیست؟ آموزش عیب‌یابی خطاها با مثال عملی

Debug در Laravel چیست؟

Debug یا عیب‌یابی، فرایندی است که در آن علت رفتار نادرست برنامه را پیدا می‌کنیم و برای برطرف کردن آن اقدام می‌کنیم.

فرض کنید یک پروژه Laravel دارید و هنگام ثبت سفارش، به‌جای دریافت پاسخ موفق، خطای 500 نمایش داده می‌شود. این خطا به‌تنهایی مشخص نمی‌کند که مشکل از کجاست. ممکن است علت آن یک خطای PHP، کوئری اشتباه دیتابیس، تنظیمات نادرست محیط، نبودن یک کلاس یا مشکل ارتباط با سرویس خارجی باشد.

در چنین شرایطی باید مرحله‌به‌مرحله اطلاعات مربوط به اجرای برنامه را بررسی کنید تا به علت اصلی خطا برسید.

Laravel ابزارهای مختلفی برای این کار در اختیار شما قرار می‌دهد، از جمله:

• dd() برای نمایش اطلاعات و متوقف کردن اجرای برنامه
• dump() برای نمایش اطلاعات بدون توقف اجرای برنامه
• فایل‌های لاگ برای ثبت خطاها و رویدادهای مهم
• ابزارهای مدیریت Exception برای بررسی و گزارش خطاها
• ابزارهای بررسی کوئری‌های دیتابیس
• دستورات Artisan برای بررسی وضعیت پروژه

در این مقاله یاد می‌گیریم چگونه از این ابزارها در پروژه‌های واقعی استفاده کنیم.

چرا Debug در پروژه‌های Laravel اهمیت دارد؟

در پروژه‌های کوچک، ممکن است بتوانید با بررسی چند خط کد علت خطا را پیدا کنید. اما در پروژه‌های بزرگ، یک درخواست ممکن است از Route، Middleware، Controller، Service، Model و دیتابیس عبور کند.

در این شرایط، مشاهده نتیجه نهایی کافی نیست و باید بدانید خطا در کدام مرحله رخ داده است.

Debug اصولی به شما کمک می‌کند:

1. علت خطا را سریع‌تر پیدا کنید.
2. از تغییرات غیرضروری در کد جلوگیری کنید.
3. خطاهای دیتابیس و API را بهتر بررسی کنید.
4. اطلاعات مفیدی برای عیب‌یابی مشکلات محیط عملیاتی داشته باشید.
5. تفاوت میان خطای برنامه، تنظیمات سرور و مشکل سرویس خارجی را تشخیص دهید.

نکته مهم این است که Debug فقط به معنای نمایش متغیرها نیست. عیب‌یابی مؤثر یعنی جمع‌آوری اطلاعات مرتبط، محدود کردن محدوده مشکل و بررسی فرضیه‌ها تا رسیدن به علت واقعی.

مرحله اول: استفاده از dd() در Laravel

یکی از ساده‌ترین ابزارهای عیب‌یابی در Laravel، تابع dd() است.

نام این تابع از عبارت Dump and Die گرفته شده است. این تابع اطلاعات ورودی را نمایش می‌دهد و سپس اجرای برنامه را متوقف می‌کند.

برای مثال، فرض کنید در یک Controller می‌خواهید اطلاعات درخواست را بررسی کنید:

public function store(Request $request)

{

    dd($request->all());



    // ادامه کد

}

اگر درخواست شامل نام و قیمت محصول باشد، تابع dd() اطلاعات دریافتی را نمایش می‌دهد؛ برای مثال:

[

    "name" => "Keyboard",

    "price" => "1500000"

]

این کار به شما کمک می‌کند بررسی کنید که آیا داده‌ها واقعاً به Controller رسیده‌اند یا خیر.

چه زمانی از dd() استفاده کنیم؟

این تابع در شرایط زیر مفید است:

• بررسی داده‌های دریافتی از فرم
• بررسی نتیجه یک متد
• مشاهده محتوای یک آرایه یا Collection
• بررسی وضعیت یک مدل
• پیدا کردن مرحله‌ای که اجرای کد به آن می‌رسد

برای مثال:

$product = Product::find($id);



dd($product);

با این دستور می‌توانید بررسی کنید که محصول موردنظر پیدا شده است یا مقدار متغیر null است.

نکته مهم: dd() اجرای برنامه را متوقف می‌کند. بنابراین، استفاده از آن در مسیرهایی که کاربران واقعی به آن‌ها دسترسی دارند می‌تواند باعث اختلال در عملکرد برنامه شود. پس از اتمام عیب‌یابی، آن را حذف کنید.

مرحله دوم: استفاده از dump() بدون توقف اجرای برنامه

تابع dump() شبیه dd() است، اما پس از نمایش اطلاعات، اجرای برنامه را متوقف نمی‌کند.

برای مثال:

public function index()

{

    $products = Product::all();



    dump($products);



    return view('products.index', compact('products'));

}

در این مثال، اطلاعات محصولات نمایش داده می‌شوند و اجرای کد ادامه پیدا می‌کند.

تفاوت اصلی این دو تابع به این صورت است:

اگر بخواهید چند مقدار را در یک مرحله بررسی کنید و سپس ادامه اجرای برنامه را ببینید، dump() می‌تواند مناسب باشد.

البته خروجی این توابع بسته به نوع درخواست و محیط اجرا متفاوت است. برای مثال، اگر درخواست API باشد، خروجی عیب‌یابی ممکن است پاسخ JSON را به‌هم بزند؛ بنابراین نباید این ابزارها را بدون احتیاط در پاسخ‌های عمومی API قرار دهید.

مرحله سوم: بررسی اطلاعات درخواست با request()

گاهی مشکل از خود منطق برنامه نیست، بلکه داده‌هایی که از سمت کاربر یا یک سیستم دیگر ارسال می‌شوند، با چیزی که انتظار دارید تفاوت دارند.

برای بررسی داده‌های درخواست می‌توانید از این کد استفاده کنید:

dd(request()->all());

اگر فقط یک فیلد مشخص را می‌خواهید بررسی کنید، از این روش استفاده کنید:

dd(request()->input('email'));

یا اگر می‌خواهید بررسی کنید که یک فیلد در درخواست وجود دارد یا خیر:

dd(request()->has('email'));

این دستورات برای بررسی فرم‌ها، درخواست‌های API و درخواست‌هایی که از ابزارهایی مانند Postman ارسال می‌شوند، مفید هستند.

بررسی Headerهای درخواست

گاهی مشکل از Headerهایی مانند Authorization یا Content-Type است.

برای بررسی یک Header مشخص می‌توانید بنویسید:

dd(request()->header('Content-Type'));

یا:

dd(request()->bearerToken());

دستور دوم مقدار Bearer Token را از درخواست استخراج می‌کند.

هشدار امنیتی: توکن دسترسی، رمز عبور، کلید API، اطلاعات کارت بانکی و سایر داده‌های حساس را در خروجی قابل مشاهده یا فایل‌های لاگ عمومی قرار ندهید. هنگام عیب‌یابی، اطلاعات حساس را حذف یا ماسک کنید.

مرحله چهارم: بررسی فایل‌های لاگ Laravel

در پروژه‌های واقعی، همیشه نمی‌توان از dd() استفاده کرد. برای مثال، ممکن است خطا فقط روی سرور رخ دهد یا در یک Job پس‌زمینه اتفاق بیفتد.

در چنین شرایطی، فایل‌های لاگ یکی از مهم‌ترین منابع عیب‌یابی هستند.

Laravel معمولاً فایل لاگ را در مسیر زیر ذخیره می‌کند:

storage/logs/laravel.log

مسیر و نحوه ذخیره لاگ‌ها به تنظیمات فایل config/logging.php وابسته است. اگر از کانال روزانه استفاده شود، ممکن است فایل‌هایی مانند laravel-2026-10-18.log ایجاد شوند.

مشاهده آخرین خطاها در سرور لینوکس

اگر به ترمینال سرور دسترسی دارید، می‌توانید از دستور زیر استفاده کنید:

tail -n 100 storage/logs/laravel.log

این دستور ۱۰۰ خط آخر فایل لاگ را نمایش می‌دهد.

برای مشاهده زنده تغییرات فایل:

tail -f storage/logs/laravel.log

پس از اجرای این دستور، هرگاه اطلاعات جدیدی به فایل اضافه شود، در ترمینال نمایش داده خواهد شد.

اگر فایل لاگ وجود ندارد یا به‌روزرسانی نمی‌شود، موارد زیر را بررسی کنید:

• آیا برنامه واقعاً خطا را در همین کانال ثبت می‌کند؟
• آیا مسیر ذخیره لاگ در تنظیمات تغییر کرده است؟
• آیا کاربر اجراکننده PHP اجازه نوشتن در مسیر لاگ را دارد؟
• آیا مقدار LOG_LEVEL مانع ثبت پیام موردنظر شده است؟
• آیا خطا در وب‌سرور یا PHP رخ داده و پیش از رسیدن به Laravel اتفاق افتاده است؟

در بعضی شرایط، خطاهای PHP یا وب‌سرور در لاگ‌های خود سرور ثبت می‌شوند و در فایل لاگ Laravel دیده نمی‌شوند.

مرحله پنجم: ثبت پیام دلخواه با Log

گاهی برنامه خطای واضحی نمایش نمی‌دهد، اما می‌خواهید بدانید کد تا کدام مرحله پیش رفته است.

در چنین شرایطی می‌توانید از Facade مربوط به لاگ استفاده کنید:

use Illuminate\Support\Facades\Log;



Log::info('Order processing started');

این دستور یک پیام اطلاعاتی ثبت می‌کند.

برای ثبت خطا نیز می‌توانید از متد error() استفاده کنید:

Log::error('Order processing failed');

ثبت اطلاعات تکمیلی در لاگ

فرض کنید هنگام ثبت سفارش می‌خواهید شناسه سفارش را نیز در لاگ ثبت کنید:

use Illuminate\Support\Facades\Log;



Log::info('Order processing started', [

    'order_id' => $order->id,

]);

اطلاعات تکمیلی به پیدا کردن رویداد مرتبط با یک سفارش کمک می‌کنند.

در یک پروژه واقعی می‌توانید اطلاعات غیرحساس دیگری مانند شناسه درخواست یا شناسه سرویس را نیز ثبت کنید.

ثبت Exception در لاگ

اگر بخواهید خطایی را ثبت کنید، می‌توانید از الگوی زیر استفاده کنید:

use Illuminate\Support\Facades\Log;

use Throwable;



try {

    // اجرای عملیات موردنظر

} catch (Throwable $e) {

    Log::error('Operation failed', [

        'exception' => $e,

    ]);



    throw $e;

}

در این مثال، خطا ثبت می‌شود و سپس دوباره پرتاب می‌شود تا مدیریت خطای بالاتر Laravel بتواند آن را پردازش کند.

این الگو را نباید بدون فکر در تمام قسمت‌های برنامه تکرار کرد. اگر صرفاً می‌خواهید خطا به‌صورت عادی توسط Laravel گزارش شود، ممکن است نیازی به گرفتن و ثبت مجدد آن نباشد.

همچنین در زمان ثبت لاگ باید مراقب باشید اطلاعات محرمانه یا داده‌های شخصی غیرضروری ذخیره نشوند.

مرحله ششم: بررسی خطای 500 در Laravel

خطای HTTP 500 به این معناست که هنگام پردازش درخواست، خطایی در سمت سرور رخ داده است. اما این کد به‌تنهایی علت اصلی مشکل را مشخص نمی‌کند.

برای پیدا کردن علت خطای 500، مراحل زیر را به‌ترتیب بررسی کنید.

۱. زمان وقوع خطا را مشخص کنید

بررسی کنید خطا هنگام کدام عملیات رخ می‌دهد:

• باز کردن صفحه
• ورود کاربر
• ارسال فرم
• اجرای یک API
• ارتباط با دیتابیس
• ارسال درخواست به سرویس خارجی

مشخص کردن سناریوی تکرار خطا، محدوده جست‌وجو را کوچک‌تر می‌کند.

۲. فایل لاگ را بررسی کنید

آخرین خطاهای ثبت‌شده را بررسی کنید و به دنبال اطلاعاتی مانند نام Exception، پیام خطا، فایل و شماره خط باشید.

برای مثال، پیام زیر می‌تواند نشان دهد که یک کلاس پیدا نشده است:

Class "App\Services\PaymentService" not found

در این شرایط، باید نام کلاس، Namespace، محل فایل و نحوه بارگذاری آن را بررسی کنید.

۳. تغییرات اخیر را بررسی کنید

اگر خطا پس از تغییر کد، نصب یک پکیج یا تغییر تنظیمات سرور ایجاد شده است، همان تغییرات نقطه شروع مناسبی برای بررسی هستند.

۴. لاگ وب‌سرور و PHP را نیز بررسی کنید

اگر هیچ اطلاعاتی در لاگ Laravel وجود ندارد، ممکن است خطا پیش از اجرای کامل برنامه رخ داده باشد.

در این شرایط باید لاگ‌های PHP و وب‌سرور متناسب با محیط میزبانی خود را نیز بررسی کنید.

۵. پس از رفع علت، خطا را دوباره آزمایش کنید

صرفاً ناپدید شدن صفحه خطا کافی نیست. همان سناریویی را که قبلاً باعث خطا می‌شد دوباره اجرا کنید و بررسی کنید که پاسخ مورد انتظار دریافت می‌شود.

مرحله هفتم: استفاده از APP_DEBUG

یکی از تنظیمات مهم در عیب‌یابی Laravel، متغیر APP_DEBUG در فایل .env است.

برای محیط توسعه معمولاً می‌توانید از تنظیم زیر استفاده کنید:

APP_DEBUG=true

این تنظیم به Laravel اجازه می‌دهد جزئیات بیشتری درباره خطاها نمایش دهد.

اما در محیط عملیاتی باید مقدار آن را روی false قرار دهید:

APP_DEBUG=false

نمایش جزئیات خطا در محیط عملیاتی ممکن است اطلاعات حساسی مانند مسیر فایل‌ها، جزئیات داخلی برنامه یا اطلاعات پیکربندی را در اختیار کاربران قرار دهد.

هرگز برای رفع مشکل سایت عملیاتی، APP_DEBUG=true را به‌صورت عمومی فعال نکنید. در محیط Production از لاگ‌ها و ابزارهای گزارش خطا استفاده کنید.

اگر مقدار تنظیمات را تغییر دادید و برنامه از Configuration Cache استفاده می‌کند، ممکن است لازم باشد تنظیمات کش‌شده را پاک کنید:

php artisan config:clear

این دستور تنظیمات کش‌شده را پاک می‌کند. در سرور عملیاتی، قبل از اجرای دستورات مربوط به کش، اثر آن‌ها بر محیط اجرا و روند استقرار را در نظر بگیرید.

مرحله هشتم: عیب‌یابی کوئری‌های دیتابیس

گاهی خطا از کد PHP نیست، بلکه کوئری دیتابیس نتیجه مورد انتظار را تولید نمی‌کند.

برای مثال، ممکن است محصولی که انتظار دارید پیدا شود، در نتیجه کوئری وجود نداشته باشد یا شرط جست‌وجو اشتباه باشد.

بررسی نتیجه کوئری

فرض کنید کد زیر را دارید:

$product = Product::where('sku', $sku)->first();



dd($product);

با این دستور می‌توانید بررسی کنید که آیا محصولی با کد موردنظر پیدا شده است یا خیر.

اگر مقدار null باشد، باید بررسی کنید:

• آیا مقدار $sku درست است؟
• آیا رکورد موردنظر در دیتابیس وجود دارد؟
• آیا شرط جست‌وجو با نوع و مقدار واقعی ستون مطابقت دارد؟
• آیا از اتصال و دیتابیس مورد انتظار استفاده می‌کنید؟

بررسی SQL تولیدشده

در Query Builder می‌توانید از ابزارهای dump() و dd() برای بررسی کوئری استفاده کنید:

DB::table('users')

    ->where('votes', '>', 100)

    ->dump();

این دستور اطلاعات کوئری را نمایش می‌دهد و اجرای کد را ادامه می‌دهد.

اگر بخواهید اطلاعات کوئری نمایش داده شود و اجرای برنامه متوقف شود، می‌توانید از این روش استفاده کنید:

DB::table('users')

    ->where('votes', '>', 100)

    ->dd();

در نسخه‌های جدید Laravel، متدهای dumpRawSql() و ddRawSql() نیز برای مشاهده SQL با مقادیر جایگزین‌شده در Bindingها در دسترس هستند.

DB::table('users')

    ->where('votes', '>', 100)

    ->dumpRawSql();

این ابزارها برای بررسی کوئری‌های پیچیده مفید هستند؛ اما خروجی کوئری ممکن است شامل اطلاعات حساس باشد. از نمایش یا ثبت عمومی آن در محیط عملیاتی خودداری کنید.

مرحله نهم: مدیریت Exceptionها در Laravel

Exception یا استثنا، روشی برای گزارش شرایط غیرعادی در اجرای برنامه است.

برای مثال، اگر یک سفارش پیدا نشود یا عملیات پرداخت با خطا مواجه شود، ممکن است برنامه Exception ایجاد کند.

Laravel به‌صورت پیش‌فرض سازوکار مدیریت Exception دارد و می‌تواند خطاها را گزارش کند و پاسخ مناسب تولید کند.

در نسخه‌های جدید Laravel، تنظیمات مدیریت Exception در فایل زیر انجام می‌شود:

bootstrap/app.php

ایجاد Exception اختصاصی

فرض کنید می‌خواهید برای یک سفارش نامعتبر، Exception اختصاصی داشته باشید.

فایل زیر را ایجاد کنید:

app/Exceptions/InvalidOrderException.php

سپس کد زیر را در آن قرار دهید:

<?php



namespace App\Exceptions;



use RuntimeException;



class InvalidOrderException extends RuntimeException

{

}

اکنون می‌توانید هنگام شناسایی سفارش نامعتبر، این Exception را ایجاد کنید:

throw new \App\Exceptions\InvalidOrderException(

    'The order is invalid.'

);

این کار کمک می‌کند خطاهای مربوط به سفارش از سایر خطاهای عمومی متمایز شوند.

البته تعریف Exception اختصاصی به‌تنهایی تعیین نمی‌کند که چه پاسخ HTTP به کاربر داده شود. برای این کار باید نحوه گزارش یا نمایش Exception را نیز بر اساس نیاز برنامه تنظیم کنید.

مدیریت نحوه نمایش Exception

در پروژه‌های Laravel 13 می‌توان رفتار Exceptionهای مشخص را در bootstrap/app.php سفارشی‌سازی کرد.

برای مثال، اگر بخواهید Exception مربوط به سفارش نامعتبر را با یک پاسخ JSON مشخص نمایش دهید، می‌توانید از قابلیت render() استفاده کنید:

use App\Exceptions\InvalidOrderException;

use Illuminate\Http\Request;

use Illuminate\Foundation\Configuration\Exceptions;



->withExceptions(function (Exceptions $exceptions): void {

    $exceptions->render(

        function (

            InvalidOrderException $e,

            Request $request

        ) {

            if ($request->expectsJson()) {

                return response()->json([

                    'message' => 'The order is invalid.',

                ], 422);

            }

        }

    );

})

این قطعه کد باید داخل زنجیره پیکربندی برنامه در bootstrap/app.php قرار بگیرد و با ساختار موجود فایل هماهنگ شود؛ نباید عبارت ->withExceptions() را به‌عنوان یک دستور مستقل در فایل دیگری قرار دهید.

در این مثال، برای درخواست‌هایی که پاسخ JSON انتظار دارند، پاسخ ۴۲۲ برگردانده می‌شود. در سایر درخواست‌ها، چون Callback پاسخ مشخصی برنمی‌گرداند، مدیریت پیش‌فرض Laravel می‌تواند ادامه پیدا کند.

کد وضعیت و متن پاسخ را باید مطابق قرارداد واقعی برنامه انتخاب کنید.

مرحله دهم: استفاده از ابزارهای Debug در محیط توسعه

برای پروژه‌های بزرگ‌تر، ابزارهای تکمیلی می‌توانند روند عیب‌یابی را ساده‌تر کنند.

Laravel Pail

Laravel Pail ابزاری برای مشاهده و فیلتر کردن لاگ‌های برنامه از طریق ترمینال است. این ابزار می‌تواند هنگام بررسی خطاهای در حال وقوع مفید باشد.

برای استفاده از آن، ابتدا باید پیش‌نیازهای نصب و نسخه سازگار را مطابق مستندات رسمی بررسی کنید.

پس از نصب و آماده‌سازی، معمولاً می‌توانید لاگ‌ها را با دستور زیر دنبال کنید:

php artisan pail

Xdebug

Xdebug افزونه‌ای برای PHP است که امکاناتی مانند Breakpoint، بررسی مقدار متغیرها و اجرای مرحله‌به‌مرحله کد را در اختیار توسعه‌دهنده قرار می‌دهد.

برخلاف dd() که برای نمایش سریع اطلاعات استفاده می‌شود، Debugger امکان می‌دهد اجرای برنامه را در نقاط مشخص متوقف کنید و مقدار متغیرها را در طول اجرا بررسی کنید.

راه‌اندازی Xdebug به نسخه PHP، تنظیمات محیط و IDE مورد استفاده شما وابسته است.

ابزارهای گزارش خطا

در پروژه‌های عملیاتی می‌توانید از ابزارهای گزارش خطا استفاده کنید تا خطاهای مهم در یک پنل مرکزی ثبت و بررسی شوند.

Laravel امکان اتصال به کانال‌ها و سرویس‌های مختلف گزارش‌دهی را فراهم می‌کند. انتخاب ابزار مناسب به نیاز پروژه، هزینه، سطح دسترسی و سیاست نگهداری اطلاعات بستگی دارد.

روش اصولی عیب‌یابی در پروژه‌های Laravel

وقتی با خطا مواجه می‌شوید، بهتر است به‌جای تغییر تصادفی کد، یک روند مشخص را دنبال کنید:

1. خطا را بازتولید کنید: مشخص کنید با چه درخواست یا عملیاتی رخ می‌دهد.
2. پیام خطا را بخوانید: نوع Exception، فایل و شماره خط را بررسی کنید.
3. لاگ‌های مرتبط را بررسی کنید: زمان وقوع خطا و اطلاعات مربوط به درخواست را پیدا کنید.
4. محدوده مشکل را کوچک کنید: مشخص کنید خطا در Route، Controller، Service، دیتابیس یا سرویس خارجی رخ می‌دهد.
5. فرضیه خود را آزمایش کنید: از ابزار مناسب مانند dd()، dump()، لاگ یا Debugger استفاده کنید.
6. علت اصلی را اصلاح کنید: فقط پیام خطا را مخفی نکنید؛ علت ایجاد آن را برطرف کنید.
7. سناریو را دوباره اجرا کنید: بررسی کنید مشکل واقعاً حل شده باشد.
8. تست اضافه کنید: اگر خطا از رفتار قابل تکراری ناشی شده است، برای جلوگیری از بازگشت آن تست مناسبی بنویسید.

این روش به‌ویژه در پروژه‌هایی که چندین سرویس یا API به یکدیگر وابسته‌اند، مفید است.

خطاهای رایج هنگام Debug در Laravel

۱. فعال کردن Debug در سرور عملیاتی

فعال کردن APP_DEBUG=true در محیط عملیاتی می‌تواند اطلاعات حساس برنامه را افشا کند. در Production این مقدار باید false باشد.

۲. باقی گذاشتن dd() در کد

اگر dd() در یک مسیر عمومی باقی بماند، اجرای درخواست در همان نقطه متوقف می‌شود و قابلیت موردنظر ممکن است کار نکند.

۳. بررسی نکردن لاگ وب‌سرور

همه خطاها در فایل لاگ Laravel ثبت نمی‌شوند. برخی خطاها ممکن است در سطح PHP یا وب‌سرور رخ دهند.

۴. ثبت اطلاعات محرمانه در لاگ

ثبت توکن، رمز عبور، اطلاعات پرداخت یا اطلاعات شخصی غیرضروری می‌تواند ریسک امنیتی ایجاد کند. هنگام ثبت لاگ فقط اطلاعات لازم را نگه دارید.

۵. مخفی کردن خطا به‌جای رفع علت آن

گاهی برنامه‌نویس با گرفتن Exception و نادیده گرفتن آن، از نمایش خطا جلوگیری می‌کند؛ اما مشکل اصلی همچنان وجود دارد. خطا را تنها زمانی مدیریت کنید که رفتار جایگزین مشخص و درستی برای آن تعریف کرده باشید.

۶. تغییر چند بخش به‌صورت هم‌زمان

اگر چند فایل و تنظیمات را بدون بررسی تغییر دهید، ممکن است تشخیص علت واقعی دشوارتر شود. هر بار یک فرضیه مشخص را بررسی کنید و نتیجه را بسنجید.

پرسش‌های متداول

چگونه در Laravel خطاها را Debug کنیم؟

برای خطاهای ساده می‌توانید از dd() و dump() استفاده کنید. برای خطاهای محیط عملیاتی یا خطاهایی که در پس‌زمینه رخ می‌دهند، فایل‌های لاگ و ابزارهای گزارش خطا مناسب‌تر هستند.

فایل لاگ Laravel کجاست؟

در تنظیمات پیش‌فرض رایج، فایل لاگ در مسیر storage/logs/laravel.log قرار دارد؛ اما مسیر دقیق به تنظیمات config/logging.php و کانال فعال بستگی دارد.

تفاوت dd() و dump() چیست؟

هر دو اطلاعات را نمایش می‌دهند؛ اما dd() اجرای برنامه را متوقف می‌کند و dump() پس از نمایش اطلاعات اجازه می‌دهد اجرا ادامه پیدا کند.

چرا خطای 500 در لاگ Laravel نمایش داده نمی‌شود؟

ممکن است خطا پیش از اجرای کامل Laravel رخ داده باشد، مسیر لاگ متفاوت باشد، تنظیمات ثبت لاگ مشکل داشته باشند یا دسترسی نوشتن در فایل وجود نداشته باشد. در این شرایط لاگ PHP و وب‌سرور را نیز بررسی کنید.

آیا فعال کردن APP_DEBUG=true برای رفع خطای سایت مناسب است؟

در محیط توسعه بله، اما در سرور عملیاتی خیر. در Production باید APP_DEBUG=false باشد تا جزئیات داخلی برنامه به کاربران نمایش داده نشود.

آیا Debug جایگزین تست‌نویسی است؟

خیر. Debug برای پیدا کردن علت یک مشکل استفاده می‌شود، درحالی‌که تست‌نویسی کمک می‌کند رفتارهای مورد انتظار را به‌صورت تکرارپذیر بررسی کنید. این دو روش مکمل یکدیگر هستند.

جمع‌بندی

Debug در Laravel یکی از مهارت‌های ضروری برای توسعه‌دهندگان این فریم‌ورک است. با یادگیری ابزارهایی مانند dd()، dump()، لاگ‌ها، مدیریت Exception و بررسی کوئری‌های دیتابیس می‌توانید علت بسیاری از خطاها را سریع‌تر پیدا کنید.

در محیط توسعه، ابزارهای نمایش مستقیم اطلاعات برای بررسی سریع مفید هستند؛ اما در محیط عملیاتی باید به لاگ‌های کنترل‌شده، گزارش خطا و رعایت اصول امنیتی تکیه کنید.

بهترین روش این است که ابتدا خطا را بازتولید کنید، سپس اطلاعات مرتبط را جمع‌آوری کنید، علت اصلی را پیدا کنید و پس از اصلاح، همان سناریو را دوباره بررسی کنید.

منابع رسمی

• مستندات Laravel درباره مدیریت خطاها: https://laravel.com/docs/13.x/errors
• مستندات Laravel درباره Logging: https://laravel.com/docs/13.x/logging
• مستندات Laravel درباره عیب‌یابی Query Builder: https://laravel.com/docs/13.x/queries