# Composer: el gestor de paquetes de PHP

> Composer explicado: entender composer.json, composer.lock, vendor y el autoloader, desplegar limpiamente en producción y mantener las dependencias de forma segura.

Fuente: https://phpsos.de/es/php/composer/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** Composer es el gestor de paquetes de PHP. Lee del archivo `composer.json` qué bibliotecas necesita un proyecto, las descarga en la carpeta `vendor`, registra las versiones exactas en `composer.lock` y genera un autoloader que encuentra las clases automáticamente. Así, Composer gestiona el código de su aplicación, no el propio intérprete de PHP: una actualización de Composer no cierra ninguna vulnerabilidad de PHP como PHP2Shell.

## ¿Qué es Composer y para qué se necesita?

Hoy casi ninguna aplicación PHP consta solo de código propio. Frameworks, bibliotecas de correo, generación de PDF o conexiones de pago se añaden como paquetes ya hechos. Composer, el gestor de paquetes de PHP, se encarga de que estos paquetes se reúnan en versiones compatibles y de que cada dependencia traiga consigo sus propias dependencias.

Para quienes toman decisiones esto significa: una gran parte del código que se ejecuta en su servidor procede de terceros. Es eficiente, pero exige mantenimiento. Para administradores y desarrolladores significa: quien usa Composer con orden puede saber en todo momento qué versión de qué biblioteca se ejecuta en producción.

Según la documentación de Composer, la fuente estándar de paquetes es Packagist.org. Otras fuentes, por ejemplo repositorios internos de una agencia, pueden registrarse en `composer.json` bajo `repositories`.

## composer.json, composer.lock y vendor: los tres componentes

Composer trabaja con tres elementos que conviene conocer antes de hacerse cargo de un servidor o de encargar un trabajo a una agencia.

| Componente | Contenido | ¿Va al repositorio? |
|---|---|---|
| `composer.json` | paquetes deseados con rangos de versiones (`require`, `require-dev`), reglas de autoload, ajustes | sí |
| `composer.lock` | versiones exactas resueltas de todos los paquetes, también de los indirectos | sí, expresamente según la documentación de Composer |
| `vendor/` | código descargado de los paquetes y el autoloader generado | no, se genera durante la instalación |

Bajo `require` figuran los paquetes que la aplicación necesita en funcionamiento. Bajo `require-dev` figuran herramientas para el desarrollo y las pruebas, como frameworks de pruebas o análisis estático. Esta separación es importante, porque las herramientas de desarrollo no tienen sitio en un servidor de producción.

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

Las versiones del ejemplo se han elegido solo a modo ilustrativo. Qué versiones necesita su proyecto se deduce de sus requisitos.

## install o update: la diferencia en la operación

Los dos comandos suenan parecido, pero tienen consecuencias muy distintas.

- `composer install` lee el `composer.lock` e instala exactamente las versiones registradas allí. Es reproducible y pertenece al despliegue.
- `composer update` resuelve de nuevo todas las dependencias, obtiene las últimas versiones compatibles y reescribe el `composer.lock`. Pertenece al desarrollo, con pruebas posteriores.

Según la documentación de Composer, `update` ejecuta además tras escribir el archivo lock una comprobación de seguridad (audit), salvo que se desactive con `--no-audit`. `install` no la realiza por defecto; para eso existe la opción `--audit`.

## Autoloading: cómo encuentra Composer las clases

Composer genera el archivo `vendor/autoload.php`. Una vez incluido, PHP carga cada clase solo cuando se necesita. Para el código propio, la sección `autoload` establece qué espacio de nombres está en qué carpeta. Se recomienda PSR-4, un estándar de PHP-FIG. Cómo funciona exactamente lo explica la página [Espacios de nombres y autoloading](https://phpsos.de/es/php/namespaces-autoloading/); un resumen de todos los estándares ofrece la página [Estándares PSR](https://phpsos.de/es/php/psr-standards/).

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

$log = new Monolog\Logger('app');   // se carga automáticamente cuando hace falta
```

## Composer en producción: desplegar con orden

Para el despliegue se ha impuesto un orden fijo. Lo mejor es ejecutarlo en un pipeline de compilación y no a mano en el servidor.

1. **Comprobar el archivo lock:** `composer validate` garantiza que `composer.json` es válido y que `composer.lock` está actualizado.
2. **Instalar sin paquetes de desarrollo:** `composer install --no-dev` omite `require-dev`.
3. **Optimizar el autoloader:** `--optimize-autoloader` (abreviado `-o`) convierte las reglas en una lista de clases. Con `--classmap-authoritative`, PHP carga las clases exclusivamente desde esa lista.
4. **Comprobación de seguridad:** `composer audit --locked` contrasta las versiones del archivo lock con los avisos de seguridad conocidos e informa de los paquetes abandonados.
5. **vendor fuera de la raíz web:** solo la carpeta pública con el script de entrada debería ser accesible mediante URL.

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

`composer outdated` muestra además qué paquetes instalados tienen versiones más recientes. Es la base para actualizaciones planificadas en lugar de acciones aisladas y apresuradas.

## Composer, seguridad y PHP2Shell

Composer y PHP2Shell afectan a dos niveles distintos. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están en el propio intérprete de PHP. Están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y después deben reiniciarse todos los procesos de PHP. Ningún `composer update` ni ningún paquete en `vendor` cambia nada de eso.

Aun así, Composer forma parte de toda revisión tras un incidente. Quien introduce código malicioso en un servidor también puede modificar archivos en `vendor`, y `vendor/autoload.php` se carga en cada petición. Por eso, un `composer install` nuevo a partir del archivo lock verificado en un directorio vacío es un buen método para restablecer el conjunto de paquetes. Cómo comprobar periódicamente las dependencias en busca de vulnerabilidades conocidas lo describe la guía [composer audit](https://phpsos.de/es/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Importante:**
> Un `composer audit` en verde no dice nada sobre el estado de los parches de PHP. Compruebe el entorno de ejecución de PHP por separado, por ejemplo con nuestro [servicio de parcheo de PHP](https://phpsos.de/es/leistungen/php-patch-service/).

## ¿Cómo ayuda PHP SOS en concreto?

- Inventariamos para cada aplicación la versión de PHP, los paquetes de Composer y el estado del archivo lock, separando con claridad el intérprete y las bibliotecas.
- Comprobamos si `vendor` y el archivo lock concuerdan y si hay paquetes de desarrollo o archivos modificados en producción.
- Establecemos un despliegue reproducible con `install --no-dev`, autoloader optimizado y audit.
- Tras un incidente, restablecemos el conjunto de paquetes a partir del archivo lock verificado y documentamos el resultado.


## Preguntas frecuentes

**¿Debe estar composer.lock en el repositorio Git?**  
Sí. La documentación de Composer recomienda expresamente confirmar (commit) el composer.lock. Solo así el desarrollo, la CI y la producción instalan exactamente las mismas versiones de los paquetes.

**¿Cuál es la diferencia entre composer install y composer update?**  
install instala las versiones registradas en composer.lock. update resuelve de nuevo las dependencias, obtiene versiones más recientes compatibles y reescribe composer.lock. En el servidor de producción solo corresponde install.

**¿Cierra una actualización de Composer la vulnerabilidad PHP2Shell?**  
No. Composer gestiona las bibliotecas de su aplicación, no el intérprete de PHP. PHP2Shell solo se cierra con la actualización del entorno de ejecución de PHP a una versión corregida y el reinicio de todos los procesos de PHP.

**¿Dónde debe estar la carpeta vendor?**  
Idealmente fuera del directorio web accesible públicamente. Muchos frameworks colocan en la raíz web solo una carpeta public, mientras que vendor queda un nivel por encima.

## Fuentes

- [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)