PHP 8.5 против PHP 8.4: реальные изменения, которые заметят разработчики

Я обновляю PHP с 2013 года.

Тогда это была версия 5.4. Я ничего не понимал, просто нажал «обновить» в панели хостинга. Сайт упал. Я два дня разбирался, почему.

С тех пор я отношусь к обновлениям как к операции на открытом сердце.

Когда вышла PHP 8.4, я решил подождать.

Property hooks - это круто. Я видел примеры, читал обсуждения. Но я не понимал, как они повлияют на мой код. Я смотрел на них, как на красивую, но опасную игрушку.

Два месяца я просто наблюдал. Смотрел, как ребята из Laravel и Symfony адаптируют свои фреймворки. Ждал, пока улягутся баги.

Потом обновился.

И понял, что зря ждал.

До него, если ты хотел добавить логику в свойство, приходилось писать отдельные методы:

//php
class User
{
    private string $email;

    public function setEmail(string $email): void
    {
        $this->email = strtolower(trim($email));
    }
}

В PHP 8.4 это превратилось в:

//php
class User
{
    public string $email {
        set => strtolower(trim($value));
    }
}

Я переписал несколько классов. Почувствовал себя хорошо. И забыл.

Потому что это было про синтаксис. А не про работу.

PHP 8.5 я заметил не в коде.

Я обновил проект на Laravel. Запустил тесты. Они прошли.

Я сидел и смотрел в экран.

«И это всё?»

Раньше я всегда находил что-то, что сломалось. Старый пакет, который использовал устаревшую конструкцию. Или код, который полагался на поведение, которое изменилось.

С PHP 8.5 ничего не сломалось.

Я потратил время не на то, чтобы чинить. А на то, чтобы понять, что чинить нечего.

У нас в проекте около сорока Composer-пакетов. Laravel. Очереди через Redis. API. Кастомные сервисы.

Раньше обновление было стрессом.

Ты меняешь версию - и вдруг что-то перестаёт работать. Старый пакет выдаёт ошибку:

Your composer dependencies require a different PHP version

Или код предупреждает:

Deprecated: Creation of dynamic property is deprecated

И ты начинаешь расследование. Кто виноват? Какая зависимость? Почему это работало на старой версии, но не работает на новой?

С PHP 8.5 я просто проверил:

//bash
composer check-platform-reqs

Всё зелёное.

Потом, на всякий случай:

//bash
composer why-not php 8.5

Ничего.

Я выработал для себя правило: никогда не обновлять PHP на рабочем сервере первым.

Сначала - тестовое окружение. Потом - проверка приложения.

Для Laravel-проектов это выглядит так:

//bash
php artisan test

Проверяю авторизацию, API, очереди, загрузку файлов, интеграции.

Если всё проходит - обновляю production.

Меня часто спрашивают: «PHP 8.5 быстрее PHP 8.4?»

Честно? Я не заметил.

Производительность редко меняется скачкообразно между минорными версиями. Она зависит от архитектуры проекта, базы данных, настроек сервера.

Но я всегда проверяю OPcache:

//ini
opcache.enable=1
opcache.memory_consumption=256

Это даёт больше эффекта, чем сама версия PHP.

Я не знаю, стоит ли обновлять все проекты.

Для новых - да. Если фреймворк поддерживает.

Для старых - зависит. Если есть тесты и современные зависимости - можно. Если проект просто работает и его никто не трогает - лучше не рисковать.

Часто задаваемые вопросы

PHP 8.5 лучше PHP 8.4?

PHP 8.5 - более новая версия с улучшениями языка и инструментов. Но реальная польза зависит от проекта.

Нужно ли срочно обновляться с PHP 8.4 на PHP 8.5?

Нет. Для критичных проектов лучше сначала проверить совместимость библиотек и выполнить тестовое обновление.

Поддерживает ли Laravel PHP 8.5?

Зависит от версии Laravel и установленных пакетов. Проверьте требования текущего проекта.

Нужно ли переписывать код после перехода на PHP 8.5?

В большинстве случаев нет. Но старые конструкции и устаревшие зависимости могут потребовать изменений.

Что выбрать для нового проекта в 2026 году?

Если экосистема поддерживает PHP 8.5, начинайте на актуальной версии.

Я обновляю PHP с 2013 года.

Тогда это было страшно. Сейчас - нет.

И я не знаю, что принесёт PHP 8.6. Может, новые фичи. Может, снова улучшения.

Но PHP 8.5 показал мне одну вещь: иногда лучший апдейт - тот, который ты не замечаешь.