PHP: полный мануал с примерами, функциями и ООП

Composer: устанавливаем библиотеку и подключаем её классы

Для отправки HTTP-запросов можно взять готовую библиотеку. Composer хранит список зависимостей проекта, согласует версии и создаёт файл подключения. Это отдельная программа для терминала, а не функция PHP.

Что уже пригодится. возврат результата, пространства имён

require выполняет подключаемый PHP-файл. Подключение autoload.php регистрирует загрузчики; все классы сразу в память не загружаются. Каталог vendor обычно создаёт Composer, исходники ваших классов лежат отдельно, например в src.

<?php
declare(strict_types=1);

$settings = require __DIR__ . '/settings.php';
echo $settings['shop'], "\n";

Мастерская

Следующая ступень. Далее создаём composer.json, устанавливаем пакет, подключаем автозагрузчик и разбираем соответствие namespace и папок PSR-4.

Зависимость — часть вашего приложения

Для отправки HTTP-запросов, проверки HTML или тестирования не обязательно писать всё с нуля. Composer устанавливает PHP-пакеты, проверяет ограничения версий и создаёт автозагрузчик. Но библиотека остаётся кодом, который выполняется с правами приложения. Изучайте поддержку, лицензию, совместимость PHP и расширений, а также то, действительно ли задача требует этой зависимости.

composer.json описывает допустимые версии и настройки проекта. composer.lock фиксирует конкретное разрешённое дерево зависимостей приложения. Коммит lock-файла позволяет коллегам и сборке установить те же версии. Команда install использует lock, update пересчитывает зависимости в рамках ограничений и меняет lock. Поэтому запускать update на production во время релиза — плохой способ воспроизводимой доставки.

vendor обычно не редактируют вручную: следующий install уничтожит исправление. Если в библиотеке ошибка, обновляют версию, предлагают исправление автору или применяют управляемый патч с понятным сроком жизни. Секреты приватного репозитория не кладут в публичный composer.json. Плагины и scripts Composer способны выполнять код, поэтому их включение требует понимания источника.

Имя класса связывается с файлом

{
  "name": "example/practical-shop",
  "require": { "php": "^8.2", "ext-pdo": "*" },
  "autoload": { "psr-4": { "Shop\\": "src/" } },
  "autoload-dev": { "psr-4": { "Shop\\Tests\\": "tests/" } }
}

<?php
declare(strict_types=1);

namespace Shop;

final class DeliveryPrice {
    public function forSubtotal(int $subtotalMinor): int {
    if ($subtotalMinor < 0) throw new \InvalidArgumentException('subtotal');
        return $subtotalMinor >= 500000 ? 0 : 39000;
    }
}

echo (new DeliveryPrice())->forSubtotal(100000)."
";

39000

PSR-4 сопоставляет префикс Shop\ с каталогом src. Полное имя Shop\Catalog\ProductRepository соответствует src/Catalog/ProductRepository.php. Регистр пути важен на Linux, даже если ошибка незаметна на Windows. use создаёт псевдоним имени в текущем файле, но само по себе не загружает файл. Автозагрузчик вызывается, когда PHP действительно нужен ещё неизвестный класс.

Пространство имён не создаёт границу безопасности и не делает объект singleton. Оно предотвращает столкновение имён и помогает организовать код. Функции и константы имеют отдельные особенности разрешения имён; не рассчитывайте, что PSR-4 автоматически загрузит произвольную функцию. Для общих файлов функций есть autoload.files, но каждый такой файл выполняется при подключении автозагрузчика, поэтому побочные эффекты там особенно нежелательны.

Обновление проходит тесты до релиза

composer validate --strict
composer install
composer audit
composer check-platform-reqs
# Для production-сборки из проверенного lock:
composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

Обновляйте зависимости в отдельной ветке, читайте изменения и запускайте тесты с реальной версией PHP. Ограничение ^8.2 допускает совместимые версии ветки 8, но библиотека и используемый синтаксис всё равно должны тестироваться на минимально заявленной версии. Не скрывайте несовместимость через --ignore-platform-reqs: это может дать успешную установку и падение в первом запросе.

В dev устанавливают инструменты тестов и анализа, в production-сборке обычно исключают require-dev. Но если приложение ошибочно использует dev-зависимость в рабочем коде, оно упадёт после --no-dev. Поэтому тестируется и готовый production-артефакт. Оптимизация автозагрузки уменьшает поиски файлов, а authoritative classmap требует осторожности с динамически создаваемыми классами.

Что хранить в репозитории и что выдавать веб-серверу

В репозитории приложения нужны исходники, composer.json, lock, миграции и тесты. Каталог public содержит только публичную точку входа и статические ресурсы. src, vendor, конфигурация и секреты находятся выше webroot. Сам факт расширения .php не защищает файл при ошибке конфигурации сервера: правильный корень уменьшает последствия.

В команде зафиксируйте команды установки, тестирования и сборки в README/CI. Новый разработчик должен получить воспроизводимую среду, а не угадывать версию пакета по чужому vendor. Для библиотеки политика lock может отличаться от приложения, потому что важно тестировать диапазон зависимостей пользователей. Здесь рассматривается именно развёртываемое веб-приложение.

Версии, расширения и проверка готовой сборки

Ограничение версии библиотеки выражает допустимый диапазон, а не обещание, что любой update не потребует внимания. Изменения транзитивной зависимости тоже способны повлиять на поведение. Просматривайте diff lock-файла, changelog существенных пакетов и результаты тестов. Не обновляйте десятки несвязанных компонентов одновременно без необходимости: причину регрессии будет труднее выделить.

Расширение PHP — не обычный пакет vendor. Указание ext-curl или ext-intl в require проверяет наличие, но не устанавливает системную библиотеку автоматически. В контейнере или серверном образе расширения и их системные зависимости готовят отдельным этапом. Composer check-platform-reqs проверяет реальную платформу, что особенно важно при использовании config.platform для разрешения зависимостей.

Артефакт после --no-dev должен запускаться самостоятельно с production-конфигурацией. Проверяйте автозагрузку всех точек входа, включая CLI-команды и воркеры. Иногда сайт работает, а ночной импорт падает, потому что его класс случайно находился в autoload-dev. Такой сбой обнаруживается тестом собранного артефакта, а не только тестами исходной dev-копии.

Практика: проверьте решение, а не только успешный путь

После переноса с Windows на Linux класс Shop\Catalog\Product не найден, хотя файл существует как src/catalog/product.php. Что исправлять?