# Composer: o gestor de pacotes do PHP

> Composer explicado: composer.json, composer.lock, vendor e autoloader, entrega limpa em produção e dependências mantidas em segurança.

Fonte: https://phpsos.de/pt/php/composer/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** O Composer é o gestor de pacotes do PHP. Lê no ficheiro `composer.json` que bibliotecas um projeto precisa, carrega-as para a pasta `vendor`, fixa as versões exatas no `composer.lock` e gera um autoloader que encontra as classes automaticamente. O Composer gere assim o código da sua aplicação, não o próprio interpretador PHP: uma atualização do Composer não fecha uma falha no PHP como o PHP2Shell.

## O que é o Composer e para que serve?

Hoje, quase nenhuma aplicação PHP consiste apenas em código próprio. Frameworks, bibliotecas de correio, geração de PDF ou ligações de pagamento chegam como pacotes prontos. O Composer, o gestor de pacotes do PHP, assegura que estes pacotes se juntam em versões compatíveis e que cada dependência traz as suas próprias dependências.

Para quem decide, isto significa: uma grande parte do código que corre no seu servidor provém de terceiros. É eficiente, mas exige manutenção. Para administradores e programadores, significa: quem usa o Composer corretamente consegue, a qualquer momento, rastrear que versão de que biblioteca está em produção.

A fonte predefinida de pacotes é, segundo a documentação do Composer, o Packagist.org. Outras fontes, por exemplo repositórios internos de uma agência, podem ser registadas no `composer.json` em `repositories`.

## composer.json, composer.lock e vendor: os três componentes

O Composer trabalha com três coisas que convém conhecer antes de assumir um servidor ou de contratar uma agência.

| Componente | Conteúdo | Pertence ao repositório? |
|---|---|---|
| `composer.json` | pacotes pretendidos com intervalos de versões (`require`, `require-dev`), regras de autoload, definições | sim |
| `composer.lock` | versões exatamente resolvidas de todos os pacotes, também dos indiretos | sim, segundo a documentação do Composer, expressamente |
| `vendor/` | código descarregado dos pacotes e o autoloader gerado | não, é gerado na instalação |

Em `require` constam os pacotes de que a aplicação precisa em funcionamento. Em `require-dev` constam ferramentas de desenvolvimento e testes, como frameworks de teste ou análise estática. Esta separação é importante, porque as ferramentas de desenvolvimento não têm lugar num servidor de produção.

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

As indicações de versão no exemplo foram escolhidas apenas a título ilustrativo. Que versões o seu projeto precisa resulta dos seus requisitos.

## install ou update: a diferença na operação

Os dois comandos soam parecido, mas têm consequências muito diferentes.

- `composer install` lê o `composer.lock` e instala exatamente as versões aí registadas. É reproduzível e pertence à entrega.
- `composer update` volta a resolver todas as dependências, obtém as versões mais recentes compatíveis e reescreve o `composer.lock`. Pertence ao desenvolvimento, com testes a seguir.

Segundo a documentação do Composer, o `update` executa, depois de gravar o ficheiro lock, uma verificação de segurança adicional (audit), a menos que seja desativada com `--no-audit`. O `install` não verifica por defeito; para isso existe a opção `--audit`.

## Autoloading: como o Composer encontra as classes

O Composer gera o ficheiro `vendor/autoload.php`. Uma vez incluído, o PHP só carrega cada classe quando ela é necessária. Para o código próprio, a secção `autoload` define que espaço de nomes está em que pasta. Recomenda-se o PSR-4, um padrão da PHP-FIG. Como isso funciona exatamente explica-o a página [Espaços de nomes e autoloading](https://phpsos.de/pt/php/namespaces-autoloading/); uma visão geral de todos os padrões dá-a a página [Padrões PSR](https://phpsos.de/pt/php/psr-standards/).

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

$log = new Monolog\Logger('app');   // é carregado automaticamente quando necessário
```

## Composer em produção: entregar de forma limpa

Para a entrega, consolidou-se uma ordem fixa. Corre melhor numa pipeline de build e não manualmente no servidor.

1. **Verificar o ficheiro lock:** `composer validate` garante que o `composer.json` é válido e o `composer.lock` está atualizado.
2. **Instalar sem pacotes de desenvolvimento:** `composer install --no-dev` deixa de fora o `require-dev`.
3. **Otimizar o autoloader:** `--optimize-autoloader` (abreviado `-o`) converte as regras numa lista de classes. Com `--classmap-authoritative`, o PHP carrega as classes exclusivamente a partir dessa lista.
4. **Verificação de segurança:** `composer audit --locked` verifica as versões do ficheiro lock contra comunicados de segurança conhecidos e assinala pacotes abandonados.
5. **vendor fora da raiz web:** Apenas a pasta pública com o script de entrada deve ser acessível por URL.

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

O `composer outdated` mostra adicionalmente que pacotes instalados têm versões mais recentes. É a base para atualizações planeadas em vez de ações isoladas apressadas.

## Composer, segurança e PHP2Shell

O Composer e o PHP2Shell dizem respeito a dois níveis diferentes. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio interpretador PHP. Estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e todos os processos PHP têm de ser reiniciados depois. Nenhum `composer update` e nenhum pacote em `vendor` altera isso.

Ainda assim, o Composer faz parte de qualquer verificação depois de um incidente. Quem coloca código malicioso num servidor também pode alterar ficheiros em `vendor`, e o `vendor/autoload.php` é carregado a cada pedido. Um `composer install` novo, a partir do ficheiro lock verificado, numa pasta vazia é por isso um bom método para restabelecer o conjunto de pacotes. Como verificar regularmente as dependências quanto a falhas conhecidas descreve-o o guia [composer audit](https://phpsos.de/pt/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Importante:**
> Um `composer audit` verde nada diz sobre o nível de patches do PHP. Verifique o ambiente de execução PHP em separado, por exemplo com o nosso [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).

## Como ajuda concretamente a PHP SOS?

- Registamos, para cada aplicação, a versão do PHP, os pacotes do Composer e o estado do ficheiro lock, separando de forma limpa o interpretador das bibliotecas.
- Verificamos se o `vendor` e o ficheiro lock são coerentes entre si e se há pacotes de desenvolvimento ou ficheiros alterados em produção.
- Configuramos uma entrega reproduzível com `install --no-dev`, autoloader otimizado e audit.
- Depois de um incidente, restabelecemos o conjunto de pacotes a partir do ficheiro lock verificado e documentamos o resultado.


## Perguntas frequentes

**O composer.lock tem de ir para o repositório Git?**  
Sim. A documentação do Composer recomenda expressamente fazer commit do composer.lock. Só assim o desenvolvimento, a CI e a produção instalam exatamente as mesmas versões dos pacotes.

**Qual é a diferença entre composer install e composer update?**  
O install instala as versões registadas no composer.lock. O update volta a resolver as dependências, obtém versões mais recentes compatíveis e reescreve o composer.lock. No servidor de produção só o install tem lugar.

**Uma atualização do Composer fecha a vulnerabilidade do PHP2Shell?**  
Não. O Composer gere as bibliotecas da sua aplicação, não o interpretador PHP. O PHP2Shell só se fecha com uma atualização do ambiente de execução PHP para uma versão corrigida e o reinício de todos os processos PHP.

**Onde deve estar a pasta vendor?**  
Idealmente fora da pasta web acessível publicamente. Muitos frameworks colocam na raiz web apenas uma pasta public, enquanto a vendor fica um nível acima.

## Fontes

- [Composer: utilização básica](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: interface de linha de comandos](https://getcomposer.org/doc/03-cli.md)
- [Composer: o esquema do composer.json](https://getcomposer.org/doc/04-schema.md)