Если вы хоть раз писали на PHP и вас тянуло использовать eval(), — остановитесь. Подумайте. Сделайте глубокий вдох. А теперь удалите этот код.
eval() — это функция, которая позволяет выполнить любую строку как PHP-код. Красиво звучит, да? Только на практике это выглядит как оставленный на кухне включённый газ: пока всё тихо, но один неверный параметр — и вы получаете взрыв.
🧨 Что делает eval()
Пример прост:
$code = 'echo 2 + 2;';
eval($code);
Выведет 4. И вроде бы всё замечательно. Но теперь подставим данные от пользователя:
eval($_GET['data']);
И всё. Добро пожаловать в ад под названием Remote Code Execution.
Любой, кто передаст ?data=system('rm -rf /');, получит полный контроль над вашим сервером.
⚖️ Почему она до сих пор не удалена
Вопрос справедливый. Функции вроде mysql_query() — давно в истории, а eval() живёт и здравствует.
Ответ прост: совместимость и ответственность.
PHP изначально задумывался как язык для гибких сценариев и шаблонов. eval() был частью этой идеи. А теперь это скорее артефакт старого интернета — вроде IE6 или jQuery 1.3. Никто не хочет, но кое-где без него код просто рухнет.
💡 Когда eval() уместен
Почти никогда.
Разве что вы точно знаете, что выполняете, и контролируете каждый байт. Например, вы генерируете PHP-код в изолированном окружении или создаёте шаблонизатор.
Но даже тогда — есть Twig, Blade, Latte, кэш-компиляция и нормальные API.
🧠 Альтернатива здравого смысла
Хочется посчитать выражение из строки?
Используйте парсер или библиотеку.
Нужно подставить динамику в шаблон?
Twig решит это без единой строчки eval.
Нужно загрузить настройки?
Есть JSON, YAML, INI — что угодно, только не PHP-код.
⚔️ Итог
eval() — не инструмент, а соблазн.
Это костыль, который работает ровно до того момента, пока не появится первый пользователь, который решит вас взломать.
Уважайте свой код. Уважайте сервер. Уважайте себя как разработчика.
Если видите eval() — не оправдывайтесь, а переписывайте. Потому что хороший программист не боится признать: «Так делать не стоит».