# Composer: управлението на пакети за PHP

> Composer, обяснен: разбиране на composer.json, composer.lock, vendor и autoloader, чисто внедряване в продукция и сигурна поддръжка на зависимостите.

Източник: https://phpsos.de/bg/php/composer/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Composer е управлението на пакети за PHP. Той чете от файла `composer.json` кои библиотеки са нужни на един проект, зарежда ги в папката `vendor`, записва точните версии в `composer.lock` и създава autoloader, който намира класовете автоматично. Така Composer управлява кода на Вашето приложение, а не самия интерпретатор на PHP: актуализация на Composer не затваря уязвимост в PHP като PHP2Shell.

## Какво е Composer и за какво е нужен?

Днес едва ли има PHP приложение, което да се състои само от собствен код. Framework-ове, библиотеки за поща, създаване на PDF или връзки за плащания се добавят като готови пакети. Composer, управлението на пакети за PHP, се грижи тези пакети да се съберат в подходящи версии и всяка зависимост да носи със себе си своите зависимости.

За вземащите решения това означава: голяма част от кода, който работи на Вашия сървър, идва от трети страни. Това е ефективно, но изисква поддръжка. За администраторите и разработчиците това означава: който използва Composer чисто, може по всяко време да проследи коя версия на коя библиотека работи в продукцията.

Стандартният източник на пакети според документацията на Composer е Packagist.org. Други източници, например вътрешни хранилища на една агенция, могат да се впишат в `composer.json` под `repositories`.

## composer.json, composer.lock и vendor: трите градивни елемента

Composer работи с три неща, които трябва да се познават, преди да поемете сървър или да възложите работа на агенция.

| Елемент | Съдържание | Принадлежи ли към хранилището? |
|---|---|---|
| `composer.json` | желани пакети с диапазони на версиите (`require`, `require-dev`), правила за autoload, настройки | да |
| `composer.lock` | точно разрешените версии на всички пакети, включително косвените | да, според документацията на Composer изрично |
| `vendor/` | изтегленият код на пакетите и създаденият autoloader | не, създава се при инсталацията |

Под `require` стоят пакети, от които приложението се нуждае в експлоатация. Под `require-dev` стоят инструменти за разработка и тестове, например тестови framework-ове или статичен анализ. Това разделяне е важно, защото инструментите за разработка нямат място на продукционен сървър.

```json
{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}
```

Версиите в примера са избрани само за нагледност. Кои версии са нужни на Вашия проект, следва от неговите изисквания.

## install или update: разликата в експлоатацията

Двете команди звучат сходно, но имат много различни последици.

- `composer install` чете `composer.lock` и инсталира точно записаните там версии. Това е възпроизводимо и принадлежи към внедряването.
- `composer update` разрешава всички зависимости наново, взема най-новите подходящи версии и пренаписва `composer.lock`. Това принадлежи към разработката, със следващи тестове.

Според документацията на Composer `update` след записването на lock файла допълнително изпълнява проверка на сигурността (audit), освен ако не е изключена с `--no-audit`. `install` по подразбиране не проверява; за това има опцията `--audit`.

## Autoloading: как Composer намира класовете

Composer създава файла `vendor/autoload.php`. След като бъде включен веднъж, PHP зарежда всеки клас едва когато той е нужен. За собствения код в раздела `autoload` се определя кое пространство от имена в коя папка лежи. За целта се препоръчва PSR-4, стандарт на PHP-FIG. Как точно работи това, обяснява страницата [Пространства от имена и autoloading](https://phpsos.de/bg/php/namespaces-autoloading/); преглед на всички стандарти дава страницата [PSR стандарти](https://phpsos.de/bg/php/psr-standards/).

```php
<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // зарежда се автоматично при нужда
```

## Composer в продукция: чисто внедряване

За внедряването се е наложил твърд ред. Най-добре е да се изпълнява в build pipeline, а не на ръка на сървъра.

1. **Проверка на lock файла:** `composer validate` гарантира, че `composer.json` е валиден и `composer.lock` е актуален.
2. **Инсталиране без пакети за разработка:** `composer install --no-dev` пропуска `require-dev`.
3. **Оптимизиране на autoloader:** `--optimize-autoloader` (накратко `-o`) преобразува правилата в списък на класовете. С `--classmap-authoritative` PHP зарежда класове изключително от този списък.
4. **Проверка на сигурността:** `composer audit --locked` проверява версиите от lock файла спрямо известни съобщения за сигурност и съобщава за изоставени пакети.
5. **vendor извън уеб корена:** Само публичната папка със входния скрипт трябва да е достъпна по URL.

```bash
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev
```

`composer outdated` показва допълнително кои инсталирани пакети имат по-нови версии. Това е основата за планирани актуализации вместо трескави единични действия.

## Composer, сигурност и PHP2Shell

Composer и PHP2Shell засягат две различни нива. Уязвимостите CVE-2026-109618 и CVE-2026-109619 са в самия интерпретатор на PHP. Поправени са в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 и след това всички PHP процеси трябва да се рестартират. Никакъв `composer update` и никакъв пакет във `vendor` не променя това.

Въпреки това Composer принадлежи към всяка проверка след инцидент. Който качи злонамерен код на сървър, може да промени и файлове във `vendor`, а `vendor/autoload.php` се зарежда при всяка заявка. Нов `composer install` от проверения lock файл в празна директория затова е добър метод за възстановяване на състава на пакетите. Как да проверявате редовно зависимостите за известни уязвимости, описва наръчникът [composer audit](https://phpsos.de/bg/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Важно:**
> Зеленият резултат от `composer audit` не казва нищо за състоянието на корекциите на PHP. Проверявайте средата за изпълнение на PHP отделно, например с нашата [услуга за PHP корекции](https://phpsos.de/bg/leistungen/php-patch-service/).

## Как помага PHP SOS конкретно?

- Установяваме за всяко приложение версията на PHP, пакетите на Composer и състоянието на lock файла и при това разделяме ясно интерпретатора от библиотеките.
- Проверяваме дали `vendor` и lock файлът си съответстват и дали в продукцията лежат пакети за разработка или променени файлове.
- Въвеждаме възпроизводимо внедряване с `install --no-dev`, оптимизиран autoloader и audit.
- След инцидент възстановяваме състава на пакетите от проверения lock файл и документираме резултата.


## Често задавани въпроси

**Трябва ли composer.lock да бъде в Git хранилището?**  
Да. Документацията на Composer изрично препоръчва composer.lock да се комитва. Само така разработката, CI и продукцията инсталират точно същите версии на пакетите.

**Каква е разликата между composer install и composer update?**  
install инсталира версиите, записани в composer.lock. update разрешава зависимостите наново, взема подходящи по-нови версии и пренаписва composer.lock. На продукционния сървър принадлежи само install.

**Затваря ли актуализация на Composer уязвимостта на PHP2Shell?**  
Не. Composer управлява библиотеките на Вашето приложение, а не интерпретатора на PHP. PHP2Shell се затваря само с актуализация на средата за изпълнение на PHP до поправена версия и рестартиране на всички PHP процеси.

**Къде трябва да стои папката vendor?**  
В идеалния случай извън публично достъпната уеб директория. Много framework-ове поставят в уеб корена само папка public, а vendor е едно ниво по-горе.

## Източници

- [Composer: Basic usage](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: Command-line interface](https://getcomposer.org/doc/03-cli.md)
- [Composer: The composer.json schema](https://getcomposer.org/doc/04-schema.md)