Почему я до сих пор выбираю PHP в 2026 году: Laravel, скорость разработки и нюансы

Каждые несколько лет PHP снова объявляют устаревшим. Тем временем на нём продолжают работать интернет-магазины, личные кабинеты, внутренние системы, API, SaaS-продукты и большая часть сайтов на WordPress. Я до сих пор выбираю PHP не из привычки и не потому, что «так исторически сложилось». Для многих веб-задач он даёт редкое сочетание: быстрый запуск, понятный деплой, зрелая экосистема, предсказуемая стоимость инфраструктуры и современный язык, который уже мало похож на PHP начала 2010-х.

В 2026 году актуальная стабильная ветка — PHP 8.5, а PHP 8.6 ещё находится на стадии предварительных сборок и не подходит для продакшена. Laravel 13 требует PHP 8.3 или новее. Это важно: разговор о современном PHP имеет смысл только применительно к поддерживаемой версии языка, Composer, автоматическим тестам и нормальной архитектуре. Код без типов, с SQL внутри шаблонов и глобальными переменными — не аргумент против PHP; это аргумент против плохой инженерной практики.

Короткий ответ: за что я выбираю PHP

PHP особенно хорош там, где результатом является веб-приложение: кабинет клиента, CRM, каталог, интернет-магазин, административная панель, REST API, интеграция с платёжной системой или автоматизация бизнес-процесса. Основные причины моего выбора:

• Низкий порог запуска. Приложение можно развернуть на обычном хостинге, VPS, в контейнере или на управляемой платформе.
• Быстрая разработка. Laravel закрывает маршрутизацию, валидацию, авторизацию, очереди, кеш, миграции, почту и тестирование единым стеком.
• Современный язык. Строгие типы, перечисления, атрибуты, readonly-классы, union/intersection-типы, match и удобная работа с объектами делают код намного надёжнее.
• Зрелая экосистема. Composer и Packagist дают управляемые зависимости и воспроизводимую установку через composer.lock.
• Простая операционная модель. Классическая связка Nginx + PHP-FPM не требует постоянно работающего процесса приложения и хорошо восстанавливается после сбоя.
• Понятная экономика. Для небольшого продукта не обязательно сразу строить Kubernetes-кластер или оплачивать дорогую serverless-инфраструктуру.

Это не означает, что PHP лучший язык вообще. Это означает, что у него очень сильное соответствие задаче «быстро и безопасно создать веб-продукт, который сможет сопровождать обычная команда».

Современный PHP — это типизированный объектный язык

Типизация PHP остаётся постепенной: можно поддерживать старый динамический код и одновременно писать новые модули строго. В новых проектах я включаю strict_types, типизирую параметры и возвращаемые значения, отделяю входные данные от доменных объектов и не передаю по приложению безымянные массивы.

Например, данные заказа удобно описать перечислением и неизменяемым DTO:

<?php
declare(strict_types=1);

enum OrderStatus: string
{
    case New = 'new';
    case Paid = 'paid';
    case Cancelled = 'cancelled';
}

final readonly class CreateOrderData
{
    public function __construct(
        public int $customerId,
        public int $amountInKopecks,
        public string $currency,
    ) {
        if ($this->amountInKopecks <= 0) {
            throw new InvalidArgumentException('Сумма должна быть положительной');
        }
    }
}

Такой объект нельзя случайно изменить после создания, а статус не превратится в строку с опечаткой. IDE и статический анализатор понимают контракт без дополнительной документации. Это не делает ошибку невозможной, но переносит значительную часть проблем с продакшена на этап разработки.

OOP полезно, пока оно решает задачу

Объектно-ориентированный подход в PHP нужен не ради бесконечных интерфейсов. Я использую его для явных границ: контроллер отвечает за HTTP, сервис — за сценарий приложения, репозиторий или ORM — за получение данных, DTO — за передачу данных, а инфраструктурный адаптер — за внешний API. Базовые принципы разобраны в материале «Основы ООП».

Плохой вариант — контроллер на 500 строк, который валидирует запрос, считает скидку, пишет SQL, вызывает платёжную систему и отправляет письмо. Хороший вариант — короткий контроллер, который передаёт проверенные данные одному прикладному сервису.

Почему Laravel остаётся сильным аргументом за PHP

Laravel не заменяет понимание PHP, HTTP, SQL и безопасности. Он уменьшает количество повторяющейся работы и задаёт команде общий словарь. Один разработчик узнает структуру проекта другого: маршруты, middleware, Form Request, Eloquent, jobs, events, policies, migrations и tests лежат в ожидаемых местах.

Если вы только знакомитесь с фреймворком, начните с статьи «Laravel: современный PHP-фреймворк для веб-разработки». Затем можно пройти пошаговое создание веб-приложения и отдельное руководство по интернет-магазину на Laravel.

Пример: тонкий контроллер и сервисный слой

Form Request проверяет вход, контроллер собирает DTO, а сервис выполняет бизнес-сценарий. Валидация остаётся рядом с HTTP-границей, но правило создания заказа не привязано к контроллеру.

<?php
declare(strict_types=1);

final class StoreOrderRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'customer_id' => ['required', 'integer', 'exists:customers,id'],
            'amount' => ['required', 'integer', 'min:1'],
            'currency' => ['required', Rule::in(['RUB', 'USD', 'EUR'])],
        ];
    }
}

final class OrderController
{
    public function store(
        StoreOrderRequest $request,
        CreateOrder $createOrder,
    ): JsonResponse {
        $data = $request->validated();

        $order = $createOrder(new CreateOrderData(
            customerId: (int) $data['customer_id'],
            amountInKopecks: (int) $data['amount'],
            currency: (string) $data['currency'],
        ));

        return response()->json(['id' => $order->id], 201);
    }
}

Сервис можно протестировать без реального HTTP-запроса. В контроллере нет расчёта скидок и прямых вызовов платёжного API. Если позже появится CLI-команда или импорт из очереди, тот же сценарий останется пригодным.

Composer делает зависимости управляемыми

Composer хранит ограничения версий в composer.json, а точные установленные версии — в composer.lock. Для приложения lock-файл необходимо коммитить: тогда разработчик, CI и продакшен получают один и тот же набор пакетов. На сервере выполняется composer install, а не бесконтрольный composer update.

composer validate --strict
composer install --no-dev --prefer-dist --optimize-autoloader
composer audit
php artisan optimize

composer audit помогает обнаруживать известные уязвимости зависимостей, но не заменяет ревью обновлений и тесты. Плагины Composer способны выполнять код во время установки, поэтому неизвестные пакеты нельзя подключать только потому, что у них красивое описание.

Быстрый запуск не означает примитивную архитектуру

Сильная сторона PHP — возможность начать с одного приложения без преждевременного дробления на микросервисы. Модульный монолит проще разрабатывать, тестировать, развертывать и восстанавливать. Внутри него всё равно можно держать ясные границы между каталогом, заказами, оплатой и уведомлениями.

Разделять сервисы стоит тогда, когда появилась измеримая причина: разные профили нагрузки, независимые циклы выпуска, требования к изоляции или отдельные команды. «Так делают крупные компании» — не причина добавлять сеть, брокер сообщений и распределённые транзакции в небольшой проект.

Очереди: медленная работа не должна задерживать пользователя

Отправка письма, генерация отчёта, обработка изображения и синхронизация с внешним API лучше выполняются в очереди. Пользователь быстро получает ответ, а worker обрабатывает задание отдельно. Но асинхронность добавляет важное требование: job должна безопасно переживать повторный запуск.

<?php
declare(strict_types=1);

final class SendPaidOrderReceipt implements ShouldQueue
{
    use Queueable;

    public function __construct(public readonly int $orderId) {}

    public function handle(): void
    {
        DB::transaction(function (): void {
            $order = Order::query()
                ->lockForUpdate()
                ->findOrFail($this->orderId);

            if ($order->receipt_sent_at !== null) {
                return;
            }

            Mail::to($order->customer->email)
                ->send(new PaidOrderReceipt($order));

            $order->forceFill(['receipt_sent_at' => now()])->save();
        });
    }
}

Здесь повторная доставка задания не создаст вторую отметку. Для реальных платежей одной блокировки может быть недостаточно: используйте уникальный ключ события, отдельную таблицу обработанных webhook и идемпотентность, которую поддерживает платёжный провайдер. Внешний вызов внутри длительной транзакции тоже нужно оценивать осторожно; для строгой надёжности применяют outbox-паттерн.

Кеш: ускоряем измеренное узкое место

Laravel одинаково работает с файловым кешем, базой, Redis и другими драйверами. Это удобно, но кеш не должен маскировать плохой запрос. Сначала проверяю индексы и план SQL, затем добавляю кеш туда, где данные читаются часто и имеют понятное время устаревания.

$plans = Cache::remember(
    key: 'public:plans:v3',
    ttl: now()->addMinutes(15),
    callback: fn () => Plan::query()
        ->where('is_active', true)
        ->orderBy('position')
        ->get(),
);

Суффикс версии помогает явно сбросить формат после изменения структуры. Для часто изменяемых сущностей лучше продумать инвалидирование по событию, а не выставлять случайный TTL и надеяться, что пользователи не заметят старые данные.

Производительность PHP: что действительно работает

OPcache хранит скомпилированный байткод в общей памяти, поэтому PHP не разбирает одни и те же файлы при каждом запросе. В Laravel дополнительно кешируются конфигурация, маршруты, события и Blade-шаблоны. Официальная команда php artisan optimize объединяет эти операции для продакшен-деплоя.

Практический порядок оптимизации:

1. Измерить медленные запросы, внешние API и загрузку CPU/памяти.
2. Исправить N+1-запросы и добавить обоснованные индексы.
3. Включить и настроить OPcache.
4. Вынести медленные операции в очередь.
5. Кешировать только понятные горячие данные.
6. Проверить PHP-FPM pool и лимиты памяти под реальной нагрузкой.
7. Только после профилирования рассматривать Octane, RoadRunner или FrankenPHP.

JIT не превращает любой PHP-сайт в сверхбыстрое приложение: типичный веб-запрос часто ждёт базу данных, сеть или файловое хранилище. Поэтому оптимизация SQL и архитектуры обычно даёт больше, чем погоня за синтетическим бенчмарком.

Безопасность: фреймворк помогает, но не отвечает за всё

Laravel предоставляет CSRF-защиту, валидацию, политики доступа, безопасное хеширование паролей и параметризованные запросы через Query Builder/Eloquent. Но уязвимость легко вернуть ручной склейкой SQL, выводом необработанного HTML, неверной авторизацией или открытым APP_DEBUG.

Минимальный производственный чеклист:

• APP_ENV=production и APP_DEBUG=false;
• секреты находятся вне репозитория и регулярно заменяются;
• все действия проверяют не только вход, но и права пользователя;
• зависимости обновляются после тестов, выполняется composer audit;
• корнем сайта является каталог public/, а .env недоступен из интернета;
• работают HTTPS, резервные копии, журналирование и мониторинг;
• webhook проверяется по подписи и защищается от повторной обработки;
• загрузка файлов ограничена по размеру, типу, расширению и месту хранения;
• ошибки для пользователя не раскрывают стек, SQL и секреты.

В чистом PHP используйте password_hash()/password_verify() для паролей и подготовленные выражения PDO для значений SQL. Нельзя хранить пароль с обычным SHA-256 и нельзя подставлять пользовательский ввод в строку запроса.

$statement = $pdo->prepare(
    'SELECT id, email FROM users WHERE email = :email LIMIT 1'
);
$statement->execute(['email' => $email]);
$user = $statement->fetch(PDO::FETCH_ASSOC);

Подготовленные выражения защищают значения, но не позволяют безопасно параметризовать имя таблицы, колонки или направление сортировки. Такие элементы выбираются только из заранее разрешённого списка.

Деплой PHP и Laravel остаётся понятным

Обычному приложению достаточно Nginx, PHP-FPM, базы данных и, при необходимости, Redis. Документ-корень должен указывать на public/. После установки зависимостей и миграций приложение оптимизируется, а долгоживущие worker-процессы перезапускаются, чтобы подхватить новый код.

composer install --no-dev --prefer-dist --optimize-autoloader
php artisan migrate --force
php artisan optimize
php artisan reload

Команда reload в Laravel 13 завершает долгоживущие сервисы, но вне управляемой платформы нужен process monitor, который запустит их снова. Важно иметь откат и резервную копию базы перед несовместимой миграцией. Полный разбор окружения, очередей и выбора между shared-хостингом и VPS есть в статье «Как выбрать хостинг для Laravel и PHP-проекта в 2026».

Для учебного проекта без постоянных worker-процессов может хватить качественного виртуального хостинга. Очереди, Redis, Reverb, Octane и индивидуальная конфигурация обычно требуют VPS или управляемой платформы. Если нужен VPS для практики, на сайте доступна партнёрская ссылка Beget; выбор тарифа всё равно следует делать по требованиям проекта, а не по рекламе.

Тесты и статический анализ — часть скорости, а не помеха

Быстро написать код и быстро выпустить надёжное изменение — не одно и то же. PHPUnit или Pest проверяют поведение, а PHPStan/Psalm находят несовместимые типы, недостижимые ветки и ошибки контрактов. Laravel упрощает HTTP-тесты, работу с тестовой базой и подмену очередей, почты и событий.

public function test_customer_can_create_order(): void
{
    Queue::fake();

    $customer = Customer::factory()->create();

    $response = $this->actingAs($customer->user)->postJson('/api/orders', [
        'customer_id' => $customer->id,
        'amount' => 149900,
        'currency' => 'RUB',
    ]);

    $response->assertCreated()->assertJsonStructure(['id']);
    $this->assertDatabaseHas('orders', ['customer_id' => $customer->id]);
}

Такой тест описывает бизнес-результат, а не внутреннее устройство контроллера. Он даёт команде свободу рефакторинга и снижает риск при обновлении фреймворка.

Тонкости, о которых важно помнить

1. Типы не отменяют проверку входных данных

strict_types помогает внутри программы, но HTTP-запрос всё равно приходит строками и неизвестными структурами. Валидировать нужно формат, диапазон, существование связанной записи и право пользователя выполнить действие.

2. ORM не отменяет SQL

Eloquent ускоряет обычную работу, но разработчик должен понимать индексы, транзакции, блокировки, планы запросов и проблему N+1. Для тяжёлого отчёта Query Builder или явный SQL иногда понятнее сложной цепочки моделей.

3. Long-running runtime меняет правила

PHP-FPM начинает запрос с чистого состояния процесса приложения. Octane и другие долгоживущие runtime сохраняют объекты в памяти между запросами. Нельзя оставлять пользовательские данные в singleton, нужно следить за утечками памяти и корректно перезагружать worker после деплоя.

4. Обратная совместимость требует дисциплины

Большая экосистема означает проекты разных эпох. Новый проект не должен копировать соглашения PHP 5 только ради совместимости с неиспользуемым пакетом. Зависимости фиксируются, обновления проходят через staging, тесты и статический анализ.

5. Дешёвый хостинг имеет реальные ограничения

На shared-хостинге могут отсутствовать нужная версия PHP, Redis, Supervisor и долгоживущие процессы. Это ограничение тарифа, а не языка. До выбора площадки составьте список процессов, расширений, памяти, диска и резервного копирования.

Когда я не выбираю PHP

Честный выбор стека начинается с ограничений. Я рассмотрю другой язык или отдельный сервис, если ядро задачи — длительные CPU/GPU-вычисления, embedded-разработка, нативное мобильное приложение, драйвер, жёсткое реальное время или специфичная научная экосистема. Python удобнее для многих ML-задач, Go — для компактных сетевых сервисов и простой конкурентности, Rust — когда критичны контроль памяти и системный уровень.

Даже тогда PHP может оставаться хорошим веб-контуром: личный кабинет и биллинг работают на Laravel, а вычисление выполняет специализированный сервис. Polyglot-архитектура оправдана, если границы понятны и дополнительная сложность окупается.

Как я принимаю решение о стеке

1. Что строим? Контентный сайт, CRUD-система, магазин, API, real-time сервис или вычислительную платформу.
2. Какая команда будет сопровождать продукт? Технология должна быть доступна не только автору первой версии.
3. Где приложение будет работать? Shared, VPS, контейнеры, управляемое облако.
4. Какие есть интеграции? Платежи, 1С, почта, Telegram, внешние API.
5. Каковы требования к нагрузке и восстановлению? RPS, объём данных, RTO/RPO, допустимый простой.
6. Как тестируем и обновляем? CI, staging, миграции, откат, мониторинг.

Если это обычный веб-продукт, команда знает PHP, а требования не противоречат модели языка, PHP и Laravel часто дают лучший результат по сумме скорости разработки, стоимости и сопровождаемости.

Практический старт нового проекта

1. Выберите поддерживаемую версию PHP; для нового Laravel 13 требуется PHP 8.3+.
2. Создайте проект через Composer и сохраните composer.lock.
3. Включите strict_types для собственного кода и настройте единый стиль.
4. Добавьте PHPStan/Psalm, PHPUnit/Pest и проверки в CI.
5. Отделите HTTP-слой от бизнес-сценариев.
6. Не переносите секреты в репозиторий или Docker-образ.
7. Подготовьте staging, резервное копирование и сценарий отката.
8. Измеряйте производительность до сложной оптимизации.

Итог

Я выбираю PHP в 2026 году не потому, что игнорирую новые технологии, а потому, что современный PHP решает веб-задачи прагматично. PHP 8.5 даёт сильную типовую систему и удобные возможности языка, Composer управляет зависимостями, Laravel 13 предоставляет цельную платформу, а инфраструктура масштабируется от недорогого хостинга до очередей, Redis и нескольких инстансов.

Главное — не путать простоту старта с разрешением писать хаотичный код. Поддерживаемая версия PHP, строгие типы, OOP с понятными границами, тесты, статический анализ, безопасный деплой и измеримая производительность превращают PHP из «языка для страничек» в нормальный инструмент разработки бизнес-систем.

Официальная документация

• Поддерживаемые версии PHP — сроки активной поддержки и исправлений безопасности.
• PHP 8.5: обзор возможностей и руководство по миграции.
• Объявления типов в PHP, перечисления и readonly-классы.
• PHP OPcache, password_hash() и PDO::prepare().
• Composer: базовое использование и lock-файл.
• Laravel 13: release notes, деплой, валидация, очереди, кеш и тестирование.

FAQ

PHP актуален в 2026 году?

Да. PHP 8.5 находится в активной поддержке, PHP 8.4 также поддерживается, а Laravel 13 работает на PHP 8.3 и новее. Для нового проекта не следует использовать ветку PHP, срок поддержки которой закончился.

Что выбрать: чистый PHP или Laravel?

Для небольшой утилиты или простого endpoint чистого PHP может быть достаточно. Для бизнес-приложения Laravel обычно выгоднее: в нём уже согласованы валидация, авторизация, миграции, очереди, кеш, почта и тестирование.

Laravel медленный?

Фреймворк имеет накладные расходы, но в большинстве бизнес-систем задержку определяют SQL, внешние API и архитектура. OPcache, artisan optimize, индексы, очереди и разумный кеш закрывают типовые проблемы. Octane нужен только после измерений.

Можно ли разместить Laravel на обычном хостинге?

Да, если хостинг поддерживает нужную версию PHP, Composer/SSH, правильный document root и cron. Для постоянных очередей, Redis, Reverb или индивидуальной настройки лучше VPS либо управляемая Laravel-платформа.

Безопасен ли PHP?

Безопасность зависит от поддерживаемой версии, кода, зависимостей и настройки сервера. Используйте валидацию, проверку прав, подготовленные запросы, безопасное хеширование паролей, обновления, HTTPS, резервные копии и отключённый debug в продакшене.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.