Ответ
Xdebug — мой основной инструмент для отладки и профилирования PHP-приложений в разработке. Я использую его в нескольких сценариях:
-
Пошаговая отладка в IDE (PhpStorm): Настраиваю отладку для проектов, работающих в Docker-контейнерах. Это позволяет устанавливать точки останова, инспектировать переменные в реальном времени и пошагово выполнять код, что незаменимо для анализа сложной логики.
Конфигурация для Docker (
Dockerfileилиdocker-compose.override.yml):# php.ini или конфиг Xdebug zend_extension=xdebug.so xdebug.mode=debug xdebug.client_host=host.docker.internal xdebug.start_with_request=yes xdebug.log=/tmp/xdebug.log # Для диагностики проблем -
Профилирование производительности: Включаю
xdebug.mode=profileдля генерации файловcachegrind, которые затем анализирую в QCacheGrind или PhpStorm. Это помогает находить узкие места — медленные запросы к БД, тяжелые циклы или неоптимальные алгоритмы. -
Анализ трассировки (Trace): Иногда использую
xdebug.mode=traceдля логирования всех вызовов функций, их аргументов и времени выполнения в файл. Это полезно для отладки сложных скриптов, где пошаговая отладка непрактична.
Важное замечание: Из-за значительного падения производительности я всегда отключаю Xdebug на production-серверах и в CI-окружении, используя отдельные конфигурационные файлы или переменные окружения.
Ответ 18+ 🔞
Да ты послушай, что за зверь такой — Xdebug! Это ж, блядь, не просто расширение, это целый спасательный круг, когда твой код ведёт себя как последняя мартышлюшка и ты нихуя не понимаешь, где он накосячил.
Вот смотри, как я его юзаю, чтобы не сойти с ума:
-
Пошаговая отладка прямо в IDE (PhpStorm). Это, ёпта, святое! Запускаешь проект в Docker-контейнере, настраиваешь эту магию, и всё — ты бог. Ставишь точку останова где угодно, и код встаёт как вкопанный. Можно тыкать в каждую переменную, смотреть, что у неё внутри, и шагать дальше, строчка за строчкой. Особенно кайфово, когда логика запутанная, как три китайца в одной шкуре. Без этого — только
var_dumpи молитвы, а это, простите, каменный век.Конфиг для Docker — выглядит страшно, но работает:
# php.ini или конфиг Xdebug zend_extension=xdebug.so xdebug.mode=debug xdebug.client_host=host.docker.internal xdebug.start_with_request=yes xdebug.log=/tmp/xdebug.log # На всякий пожарный, если всё накрылось медным тазом -
Профилирование, чтобы найти, где тормозит. Включаешь
xdebug.mode=profile, запускаешь скрипт, и он нагенерит кучу файловcachegrind. Потом открываешь их в QCacheGrind и просто офигеваешь: вот этот запрос к базе жрёт 90% времени, а этот цикл делает овердохуища итераций. Сразу видно, куда бить. Без профилирования ты как слепой кот — тыкаешься наугад и надеешься. -
Трассировка (Trace) для самых хитрых жоп. Бывает, пошагово отлаживать — себя не уважать, слишком много всего. Тогда включаешь
xdebug.mode=trace, и он пишет в лог вообще всё: кто какую функцию вызвал, с какими аргументами и сколько времени на это потратил. Открываешь потом этот лог — и вся картина как на ладони. Пиздецкое удобство, когда больше не осталось идей.
И главное, запомни как "Отче наш": Xdebug — это инструмент для разработки, а не для продакшена. Он жрёт ресурсы, как не в себя, и тормозит всё в хлам. На боевых серверах и в CI его нужно вырубать нахуй, будь здоров. Иначе будет вам хиросима, а не сайт. Обычно это делается через отдельные конфиги или переменные окружения — чтобы случайно не задеплоить эту тяжёлую артиллерию к клиентам.