PHP en 2026: guía completa de PHP 8.5 y comparación con otros lenguajes web

Cada cierto tiempo vuelve a aparecer la misma sentencia: «PHP está muerto». Resulta curioso escucharla mientras seguimos encontrando PHP detrás de WordPress, tiendas electrónicas, portales empresariales y aplicaciones que utilizamos todos los días. Muchas críticas tienen su origen en experiencias con PHP 5, proyectos mal estructurados o código que lleva años sin mantenimiento. Esos problemas existen, pero no describen por sí solos al lenguaje que tenemos en 2026.

Si estás empezando en el desarrollo web, o si llevas tiempo programando y quieres saber qué lugar ocupa PHP frente a Node.js, Python, Java o C#, esta guía pretende ayudarte a decidir con conocimiento. Empezaremos por sus fundamentos, prepararemos un entorno de trabajo y construiremos ejemplos sencillos. Después veremos Composer, Laravel, Symfony, la seguridad, el rendimiento y las alternativas actuales. La idea no es defender PHP a toda costa, sino entender dónde sigue teniendo sentido utilizarlo.

Última revisión técnica: 11 de octubre de 2026. Las cifras de adopción están fechadas; cambiarán con el tiempo.

Contenido de esta guía

¿Qué es PHP y cómo funciona?

PHP (PHP: Hypertext Preprocessor) es un lenguaje de programación de propósito general que encontró en la Web su terreno natural. Nació en los años noventa para facilitar la creación de páginas dinámicas, pero desde entonces ha incorporado orientación a objetos, declaraciones de tipos, bibliotecas compartidas y herramientas que permiten trabajar en proyectos de considerable tamaño.

Para entenderlo, imaginemos una tienda en línea. Cuando entras en la página de un producto, tu navegador solicita una dirección al servidor. La aplicación PHP comprueba qué producto has pedido, consulta el precio y las existencias en la base de datos y prepara una respuesta, ya sea HTML o JSON. El navegador recibe el resultado, no el código PHP que lo ha generado. Por eso PHP suele trabajar junto a HTML, CSS y JavaScript, no en sustitución de ellos.

También podemos ejecutar PHP desde la terminal para importar archivos, automatizar tareas administrativas, procesar colas o generar informes. Esa posibilidad pasa inadvertida cuando solo lo asociamos con páginas web, y resulta bastante útil en servidores donde ya tenemos PHP instalado. Su especialización web favorece los proyectos tradicionales, aunque otras cargas de trabajo pueden resolverse mejor con herramientas distintas.

Antes de aprender PHP: ¿Cómo está construida una aplicación web?

Si nunca has desarrollado una aplicación web, merece la pena empezar por el mapa general. En Internet hay dos extremos: el cliente, normalmente un navegador, y el servidor, que recibe peticiones, procesa información y devuelve respuestas. Entre ambos se utiliza HTTP y, en las conexiones seguras, HTTPS. El servidor no es necesariamente una sola máquina: puede haber un proxy, varias instancias de la aplicación, cachés y bases de datos.

El navegador interpreta HTML para organizar el contenido, CSS para presentarlo y JavaScript para añadir comportamiento. PHP se ejecuta habitualmente en el servidor y genera HTML o datos, como JSON. Aprender PHP no significa que puedas olvidar HTML, CSS o JavaScript: son piezas complementarias.

Qué ocurre cuando visitas una página

1. Escribes una URL. El navegador consulta el DNS y establece una conexión con el servidor correspondiente.
2. Envía una petición HTTP, por ejemplo GET /productos/15, normalmente mediante HTTPS.
3. El servidor web o proxy dirige la petición a PHP-FPM o a otro runtime que ejecute la aplicación.
4. PHP valida la petición, ejecuta la lógica, consulta la base de datos o la caché y construye la respuesta.
5. El servidor devuelve un código HTTP, cabeceras y un cuerpo. El navegador muestra el resultado o lo entrega al JavaScript de la página.

Navegador
   │ HTTPS: GET /productos/15
   ▼
Servidor web / proxy (Nginx, Apache o Caddy)
   │
   ▼
Aplicación PHP (PHP-FPM o runtime persistente)
   ├── Lógica y validación de datos
   ├── Base de datos: MySQL / PostgreSQL
   ├── Caché: Redis (opcional)
   └── Cola de trabajos (si procede)
   │
   ▼
Respuesta HTTP: 200 + HTML o JSON
   │
   ▼
Navegador / cliente móvil / otra aplicación

HTTP tiene métodos como GET, POST, PUT, PATCH y DELETE, y respuestas como 200 (correcto), 201 (creado), 400 (petición incorrecta), 401 (no autenticado), 403 (sin permisos), 404 (recurso inexistente) o 500 (error del servidor). No son detalles accesorios: una API bien diseñada comunica su resultado mediante estos códigos. Puedes aprenderlos en la documentación HTTP de MDN.

Páginas renderizadas, APIs y aplicaciones de página única

PHP puede generar páginas HTML en el servidor para que el navegador las presente directamente, alimentar una interfaz JavaScript mediante una API JSON o combinar ambos enfoques. Una web clásica renderizada en servidor no es una tecnología anticuada: suele simplificar SEO, formularios y navegación. Una aplicación con React o Vue puede ofrecer experiencias muy interactivas, pero exige gestionar más estado, recursos y comunicación. La elección depende del proyecto, no de una regla que obligue a hacer todo como una SPA.

Para seguir esta guía te resultará útil conocer lo básico de archivos y directorios, editar código, utilizar una terminal y entender los fundamentos de desarrollo web de MDN. No hace falta dominar todas esas áreas antes de escribir tu primer script, pero conviene avanzar en paralelo.

¿PHP sigue siendo importante? Qué indican las cifras

Empecemos por los números, que ayudan a separar percepciones de realidad. Según W3Techs, el 11 de octubre de 2026 PHP aparece en el 69,7 % de los sitios cuyo lenguaje del servidor se ha podido identificar. Si miramos solamente el millón de sitios mejor clasificados, la proporción es del 64,7 %; entre los primeros mil, del 58,8 %. Es una presencia enorme, aunque menor en los sitios de mayor tráfico.

Quizás hayas visto estadísticas de finales de 2025 que hablaban de alrededor del 72 % de los sitios identificables y el 67 % del primer millón. Esas cifras no contradicen las actuales: corresponden a otra fecha. Lo que no debemos hacer es presentarlas como una medición exacta del 31 de diciembre sin conservar el registro original. Al estudiar la evolución de una tecnología, la fecha y el método de medición importan tanto como el porcentaje.

Ahora bien, hay varios detalles que conviene tener presentes antes de sacar conclusiones:

• Denominador: se cuentan sitios donde W3Techs logra reconocer el lenguaje backend; no todos los sitios de Internet.
• Universo: un sitio puede utilizar varios lenguajes y la tecnología no siempre es detectable desde fuera. El porcentaje tampoco equivale a cuota de desarrolladores, contratos nuevos, repositorios o aplicaciones empresariales internas.
• Composición: la amplia instalación de WordPress y otras plataformas basadas en PHP influye mucho. Ser dominante en sitios existentes no demuestra ser el lenguaje más elegido para nuevos proyectos.

Por tanto, estas cifras demuestran la vigencia de una enorme base instalada, no que PHP gane todas las encuestas de programadores ni que sea la opción más utilizada en cada proyecto nuevo. WordPress explica una parte importante de su presencia. Precisamente por eso la experiencia con PHP sigue teniendo valor: detrás de muchos de esos sitios hay empresas, tiendas y servicios que necesitan evolucionar su software durante años.

Por qué PHP sigue estando entre las opciones más competitivas para desarrollo web

Decir que PHP es «el mejor» lenguaje sin fijar el tipo de proyecto sería una afirmación imposible de demostrar. Pero sí podemos identificar evidencias verificables de que sigue siendo una de las opciones más sólidas para desarrollar y mantener aplicaciones web. Son argumentos acumulativos: ninguno por sí solo decide la arquitectura.

1. Una base instalada que sigue necesitando desarrollo

Además de las cifras de PHP que acabamos de comentar, W3Techs sitúa a WordPress en el 40,1 % de todos los sitios examinados el 11 de octubre de 2026, con el 58,6 % del mercado de CMS detectables. WordPress está construido principalmente sobre PHP. Esto no permite atribuir todos los sitios WordPress al mismo estilo de código PHP, ni implica que todas las empresas deban usar ese CMS. Sí ayuda a entender por qué existe tanta infraestructura, formación, alojamiento y software alrededor del lenguaje.

2. Un ecosistema real, no solo una comunidad en redes sociales

El balance de Packagist de septiembre de 2026 documenta más de 469.000 paquetes y más de 200.000 millones de instalaciones acumuladas. No es una medición de productividad individual, pero sí muestra que bibliotecas, herramientas de CI y aplicaciones dependen activamente del repositorio. La existencia de PSR, Composer y herramientas de calidad reduce el coste de incorporar componentes y trabajar en equipo.

3. Varias arquitecturas con un mismo lenguaje

PHP-FPM sigue siendo adecuado para una gran cantidad de sitios; Laravel Octane, Symfony Runtime, FrankenPHP, RoadRunner y Swoole amplían las posibilidades para aplicaciones con otras necesidades de concurrencia y latencia. La existencia de alternativas es valiosa: podemos comenzar con una infraestructura simple y evolucionar cuando la carga lo justifique, sin dar por sentado que debamos reescribir toda la aplicación en otro lenguaje.

4. Productividad y costes: ventajas condicionadas, no cifras mágicas

Laravel y Symfony resuelven muchas necesidades habituales sin crear componentes desde cero, y numerosos proveedores soportan PHP. Esto puede traducirse en tiempos de desarrollo y costes operativos favorables, especialmente en proyectos convencionales o equipos que ya dominan el ecosistema. No he encontrado una medición universal que permita afirmar que PHP siempre cuesta menos o produce más líneas útiles por hora que Python, Java o TypeScript. Para una decisión empresarial seria hay que comparar con un proyecto y un equipo reales.

5. Evolución del lenguaje y mantenimiento institucional

Las mejoras recientes del motor y del lenguaje se publican en php.net. Además existe The PHP Foundation, que contribuye a sostener el desarrollo del núcleo con financiación y trabajo de ingeniería. Ningún proyecto open source es inmune a vulnerabilidades o problemas de mantenimiento, pero PHP dispone de un proceso público de releases y seguimiento de seguridad.

La valoración, por tanto, no es «PHP gana a todos». Es más concreta: para CMS, comercio electrónico, aplicaciones administrativas y APIs de negocio, PHP cuenta con una combinación contrastable de madurez, herramientas y opciones de ejecución. Frente a una alternativa, la decisión debe considerar costes de aprendizaje, operaciones, bibliotecas, requisitos y experiencia del equipo.

De PHP 5 a PHP 8.5: qué cambió de verdad

Quienes programamos desde hace años hemos visto lo mucho que puede cambiar un lenguaje sin perder su identidad. PHP 5 permitió construir muchísimas aplicaciones, pero también dejó una reputación asociada al código mezclado con HTML, las conversiones implícitas y los proyectos sin una arquitectura clara. PHP 7 mejoró notablemente la ejecución, y la familia PHP 8 continuó modernizando tanto el lenguaje como las herramientas disponibles.

El lenguaje moderno

Hoy podemos declarar tipos en parámetros, resultados y propiedades; utilizar uniones e intersecciones de tipos, expresiones match, el operador nullsafe, enumeraciones, atributos y clases readonly. También disponemos de namespaces, autoloading, funciones anónimas y herramientas de análisis estático que ayudan a mantener proyectos grandes. No necesitas utilizar todas esas posibilidades para escribir una página sencilla, pero es importante saber que existen.

Esto no hace de PHP un lenguaje estático como C# o Java: sigue siendo dinámico. Lo que cambia es cuánto control decides introducir. En un proyecto pequeño quizás baste con unas pocas funciones bien organizadas; en una aplicación empresarial será razonable añadir contratos explícitos, interfaces, pruebas y análisis automático.

Novedades representativas de PHP 8.5

PHP 8.5 se publicó el 20 de noviembre de 2025. Entre sus incorporaciones están el operador de tubería (|>) para encadenar transformaciones, nuevas API de URI, operaciones de clonación con modificación de propiedades y el atributo #[\NoDiscard], que ayuda a detectar resultados ignorados inadvertidamente.

Veamos primero el operador de tubería. Su ventaja se aprecia cuando debemos realizar varias operaciones consecutivas sobre un mismo valor, sin ir anidando llamadas dentro de otras:

<?php
declare(strict_types=1);

$titulo = '  PHP 8.5 Released  ';
$slug = $titulo
    |> trim(...)
    |> (fn(string $texto): string => str_replace(' ', '-', $texto))
    |> strtolower(...);

echo $slug; // php-8.5-released

Otra incorporación es la extensión URI. Facilita analizar direcciones web con reglas más claras que las que ofrecían algunas soluciones tradicionales:

<?php
use Uri\Rfc3986\Uri;

$uri = new Uri('https://www.php.net/releases/8.5/en.php');
echo $uri->getHost(); // www.php.net

Estos ejemplos requieren PHP 8.5. Si trabajas con PHP 8.3 o 8.4, tendrás que utilizar otras formas de hacer lo mismo. Al revisar este artículo, la actualización estable de esa rama era PHP 8.5.11, publicada el 24 de septiembre de 2026; PHP 8.6 continuaba en fase de pruebas. Antes de actualizar un servidor, consulta las versiones con soporte oficial y comprueba la compatibilidad de tu aplicación.

Otras novedades de PHP 8.5 que merece la pena conocer

El operador de tubería y la extensión URI son los cambios más visibles, pero la versión también introduce mejoras que pueden resultar especialmente útiles al diseñar bibliotecas, aplicaciones y herramientas:

• Clone with: permite clonar un objeto modificando determinadas propiedades mediante clone($objeto, ['propiedad' => $valor]); resulta muy práctico con objetos de valor y clases readonly.
• #[\NoDiscard]: emite una advertencia si descartamos el resultado de una función o método marcado con ese atributo. Puede evitar que se ignore por accidente el resultado de una operación importante.
• array_first() y array_last(): devuelven el primer o último valor de un array, respectivamente; si el array está vacío, devuelven null. No deben confundirse con funciones que devuelven claves.
• Closures y callables en expresiones constantes: amplían lo que puede utilizarse, por ejemplo, en ciertos atributos y valores por defecto.
• Conexiones cURL compartidas persistentes: la nueva curl_share_init_persistent() permite reutilizar determinados recursos entre peticiones cuando está disponible la extensión correspondiente.
• Diagnóstico y API: mejoras en las trazas de errores fatales, atributos adicionales, control de cookies y funciones de inspección del manejador de errores y excepciones.

Veamos un ejemplo de clonación con propiedades. Este código solo funciona desde PHP 8.5:

<?php
readonly class Color
{
    public function __construct(
        public int $rojo,
        public int $verde,
        public int $azul,
        public int $alfa = 255
    ) {}

    public function conAlfa(int $alfa): self
    {
        return clone($this, ['alfa' => $alfa]);
    }
}

$colorOriginal = new Color(79, 91, 147);
$semitransparente = $colorOriginal->conAlfa(128);

Las novedades también traen incompatibilidades y deprecaciones. PHP 8.5 desaconseja algunas formas antiguas de conversión de tipos y de serialización, y modifica determinados casos que antes eran aceptados. Si estás actualizando un proyecto real, consulta la presentación oficial de PHP 8.5 y la guía completa de migración. La lista anterior resume los cambios más relevantes; no sustituye al changelog ni a las notas de compatibilidad.

Breve historia de PHP y evolución de sus capacidades

PHP nació del trabajo de Rasmus Lerdorf en 1995 y fue evolucionando gracias a una comunidad internacional de desarrolladores. PHP 5 consolidó la orientación a objetos; PHP 7, publicado en 2015, renovó el motor y mejoró su rendimiento; PHP 8 comenzó a publicarse en 2020 y ha añadido mejoras importantes a la expresividad, los tipos y las herramientas del lenguaje. Las versiones 8.x no son un único salto: cada rama incorpora características concretas y tiene su propio ciclo de mantenimiento.

Entre las novedades que más conviene conocer, incluso aunque todavía no las utilices, están las property hooks de PHP 8.4: permiten definir qué ocurre cuando se lee o escribe una propiedad sin tener que simularlo todo con métodos separados. Su utilidad está en modelar datos y validaciones de forma legible; requieren conocer bien sus restricciones para no esconder trabajo costoso dentro de una simple lectura.

<?php
declare(strict_types=1);

// Requiere PHP 8.4 o superior.
class Usuario
{
    public string $nombre {
        set(string $valor) => trim($valor);
    }
}

$usuario = new Usuario();
$usuario->nombre = '  Ana  ';
echo $usuario->nombre; // Ana

Esta sintaxis es distinta de un setter clásico y no funciona en versiones anteriores. Para comprenderla en profundidad, consulta la referencia de property hooks.

Tipos modernos, análisis estático y concurrencia: conceptos que conviene separar

La presencia de Fibers desde PHP 8.1 es relevante porque permite suspender y reanudar flujos de ejecución de forma cooperativa. Una fibra no es un hilo del sistema operativo y no significa que cualquier script vaya a atender más peticiones en paralelo. Bibliotecas y runtimes específicos pueden apoyarse en ellas para gestionar concurrencia asíncrona. Del mismo modo, introducir anotaciones de tipos no hace que PHP se compile con el mismo modelo que Java o Rust: los contratos se aplican en tiempo de ejecución y herramientas externas pueden añadir análisis estático antes de desplegar.

Compatibilidad y soporte de versiones

Cuando aparece una rama nueva de PHP, no se vuelve insegura automáticamente la anterior. Las ramas cuentan con períodos de soporte activo y mantenimiento de seguridad, definidos en php.net. También hay cambios incompatibles que afectan a extensiones, funciones obsoletas y código heredado. Antes de actualizar una tienda, CMS o API, revisa la documentación de migración, actualiza dependencias en un entorno de pruebas y ejecuta la batería de test. PHP 8.6 está previsto para el futuro, pero no debe confundirse una versión candidata con una actualización estable lista para producción.

Cómo instalar PHP y preparar el entorno de desarrollo

Para dar los primeros pasos no hace falta instalar un sistema enorme. Con el intérprete PHP, un editor de código y una terminal ya podemos empezar. Composer será nuestra siguiente herramienta. La base de datos, el servidor web completo y los frameworks pueden esperar hasta que realmente los necesitemos.

GNU/Linux (Ubuntu o Debian)

En Ubuntu, Debian y distribuciones basadas en APT, lo más sencillo es comenzar con los paquetes disponibles en sus repositorios. Ten en cuenta que la versión instalada dependerá de la distribución: ejecutar estos comandos no significa que vayas a obtener necesariamente PHP 8.5.

sudo apt update
sudo apt install php-cli php-mbstring php-xml php-curl php-sqlite3
php -v
php -m

Cuando un proyecto exige una versión determinada, conviene preparar un entorno que la proporcione sin alterar otros servicios del equipo. Esto es especialmente importante en un VPS con WordPress, Nextcloud u otras aplicaciones: cambiar la rama de PHP sin revisar las extensiones y plugins puede provocar incompatibilidades perfectamente evitables.

Windows y macOS

En Windows podemos descargar los binarios desde el sitio oficial para Windows, descomprimirlos y añadir su directorio a PATH; luego comprobamos la instalación en PowerShell con php -v. En macOS, una alternativa práctica es Homebrew mediante brew install php. En ambos sistemas hay paquetes y entornos de desarrollo preparados, pero merece la pena revisar qué versión de PHP incluyen.

Para escribir el código puedes utilizar Visual Studio Code con las extensiones apropiadas o un entorno completo como PhpStorm. Ninguna de las dos elecciones te hará mejor programador por sí sola: utiliza la que te permita depurar y comprender el proyecto con menos fricción. Si tienes dudas, en Universo Digital ya explicamos las diferencias entre un editor de código y un IDE.

Tu primer programa

Vamos ahora con algo sencillo. Crea un archivo llamado hola.php, copia el siguiente código y guárdalo:

<?php
declare(strict_types=1);

$nombre = 'Universo Digital';
echo "Hola, {$nombre}\n";

php hola.php

Al ejecutarlo veremos Hola, Universo Digital y un salto de línea. La instrucción declare(strict_types=1) pide un comportamiento más estricto para determinadas conversiones escalares en las llamadas realizadas desde ese archivo; no convierte automáticamente todas las variables del programa en tipos fijos. Podemos empezar sin esa declaración, pero es útil acostumbrarse a conocer qué hace.

Entornos de desarrollo: Composer, PHP local, contenedores y depuración

Una de las ventajas históricas de PHP es que podemos comenzar sin una infraestructura complicada. Pero cuando una aplicación tiene varias dependencias, una base de datos y distintos desarrolladores, necesitamos reproducir el entorno con cierta disciplina. No recomiendo instalar diez herramientas a la vez: primero el intérprete y Composer; después, según el proyecto, un servidor local y una base de datos.

Opciones para trabajar en Windows, Linux o macOS

En Linux suele ser suficiente PHP CLI y Composer para la etapa inicial. En Windows, tanto una instalación nativa como WSL pueden ser útiles. En macOS existen instaladores y gestores como Homebrew. La recomendación práctica es utilizar el entorno que puedas mantener y depurar, no elegir una herramienta solo por popularidad.

Comprobar PHP, extensiones y configuración

php -v
php --ini
php -m
php -i
composer --version
composer diagnose

php --ini indica qué archivo de configuración utiliza la CLI; puede ser diferente del php.ini utilizado por PHP-FPM. php -m muestra extensiones disponibles, como pdo_mysql, pdo_pgsql, intl, mbstring, curl, openssl, sodium, zip y opcache. No necesitas instalarlas todas indiscriminadamente; revisa los requisitos de cada aplicación.

Configurar Composer con seguridad

Instala Composer desde su sitio oficial y sigue la verificación del instalador que allí se explica. Evita copiar a ciegas comandos de terceros que descargan y ejecutan scripts remotos. Para proyectos nuevos, Composer creará un directorio vendor/ con bibliotecas instaladas. Generalmente no se versiona vendor/: se conserva composer.lock y el despliegue reproduce las dependencias.

Si instalas extensiones nativas, recuerda que son diferentes de un paquete Composer: pueden requerir binarios, herramientas de compilación y compatibilidad con tu versión de PHP. Consulta PECL y PIE, el instalador de extensiones PHP, siempre según las instrucciones oficiales de cada extensión.

Depuración: ver dónde falla el programa

Cuando el resultado no es el esperado, insertar var_dump() puede ayudar a entender una variable, pero no debería ser nuestro único método. Xdebug permite detener la ejecución, establecer puntos de ruptura e inspeccionar el estado desde un IDE; es especialmente útil cuando intervienen varias capas. Puedes estudiar su instalación en la documentación oficial. En producción, evita habilitar indiscriminadamente sus funciones de depuración por el coste y la información sensible que podrían exponer.

Una costumbre sencilla que ahorra horas de trabajo: comprueba las versiones instaladas y guarda la configuración mínima del proyecto. Si mañana tienes que moverlo a otro equipo, deberías poder reproducirlo sin recordar una lista de ajustes manuales.

Fundamentos de PHP: sintaxis, datos, funciones y objetos

Variables, tipos y estructuras de control

Como ocurre en otros lenguajes de scripting, las variables de PHP comienzan con $. Podemos trabajar con enteros (int), decimales (float), cadenas (string), booleanos, objetos y valores nulos. También están los array, que en PHP funcionan como mapas ordenados: sirven tanto para listas como para asociaciones de clave y valor. Esa flexibilidad simplifica tareas cotidianas, aunque tiene un coste de memoria si almacenamos millones de elementos.

Para tomar decisiones contamos con if, switch y match; para recorrer datos, con foreach, for y while. Las funciones pueden indicar los tipos de sus parámetros y del resultado, como en este ejemplo de cálculo del importe de una compra:

<?php
declare(strict_types=1);

function calcularTotal(float $precio, int $cantidad): float
{
    if ($precio < 0 || $cantidad < 0) {
        throw new InvalidArgumentException('Valores no válidos');
    }

    return $precio * $cantidad;
}

echo calcularTotal(12.50, 3); // 37.5

Lo interesante no es la multiplicación, sino el pequeño contrato que hemos definido: la función acepta un precio y una cantidad, rechaza valores negativos y devuelve un número decimal. En aplicaciones reales ese tipo de comprobaciones evita que los errores se propaguen hasta la base de datos o hasta una factura.

Clases, enumeraciones y propiedades inmutables

Cuando la aplicación crece, las clases nos permiten reunir datos y comportamiento de una misma entidad. Por ejemplo, un pedido puede tener un identificador, un estado y un importe. Una enum evita que cada desarrollador escriba el estado de una forma distinta, mientras que readonly impide reasignar las propiedades después de inicializarlas. Es importante no confundir esto con una inmutabilidad absoluta de todos los objetos que puedan contener esas propiedades.

<?php
declare(strict_types=1);

enum EstadoPedido: string
{
    case Pendiente = 'pendiente';
    case Pagado = 'pagado';
}

readonly class Pedido
{
    public function __construct(
        public int $id,
        public EstadoPedido $estado,
        public float $total,
    ) {}
}

$pedido = new Pedido(1, EstadoPedido::Pagado, 49.90);
echo $pedido->estado->value; // pagado

Con el tiempo aparecerán conceptos como interfaces, traits, namespaces e inyección de dependencias. Mi consejo es no empezar por memorizar patrones de diseño: primero hay que entender funciones, objetos, errores y estructuras de datos. Después resulta mucho más fácil comprender por qué un proyecto grande necesita componentes desacoplados.

De la sintaxis a la práctica: formularios, estado, sesiones y errores

Un desarrollador web no escribe únicamente funciones: recibe información, valida formularios, consulta recursos, informa de errores y protege operaciones. PHP lleva muchos años resolviendo esos problemas, y entenderlos directamente —antes de esconderlos detrás de un framework— proporciona una base muy útil.

Variables globales y entrada de datos

PHP ofrece variables especiales como $_GET para parámetros de la URL, $_POST para datos de formulario, $_SERVER para detalles de la petición y $_FILES para subidas. Todo lo recibido de un cliente se considera no confiable. Un campo que normalmente contiene texto puede llegar como array, faltar o superar la longitud esperada. La validación tiene que ocurrir en el servidor, incluso aunque el HTML incluya required o controles JavaScript.

Ejemplo completo: recibir un formulario sin repetir los errores clásicos

Crea formulario.php. Este ejemplo reúne varias ideas: comprobación del método HTTP, sesiones, un token CSRF y escape de la salida. Es un ejercicio educativo que puedes ejecutar localmente. El token no sustituye al control de permisos ni a una configuración segura de cookies en producción.

<?php
declare(strict_types=1);

session_start();
$_SESSION['csrf'] ??= bin2hex(random_bytes(32));

$mensaje = '';
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $token = $_POST['csrf'] ?? '';
    if (!is_string($token) || !hash_equals($_SESSION['csrf'], $token)) {
        http_response_code(403);
        $mensaje = 'La sesión del formulario no es válida.';
    } else {
        $nombre = $_POST['nombre'] ?? '';
        if (!is_string($nombre) || trim($nombre) === '') {
            $mensaje = 'Escribe un nombre válido.';
        } else {
            $mensaje = 'Hola, ' . trim($nombre);
        }
    }
}
?>
<!doctype html>
<html lang="es">
<head><meta charset="utf-8"><title>Mi primer formulario PHP</title></head>
<body>
<form method="post">
    <label for="nombre">Tu nombre</label>
    <input id="nombre" name="nombre" required maxlength="80">
    <input type="hidden" name="csrf"
      value="<?= htmlspecialchars($_SESSION['csrf'], ENT_QUOTES, 'UTF-8') ?>">
    <button type="submit">Enviar</button>
</form>
<p><?= htmlspecialchars($mensaje, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') ?></p>
</body>
</html>

Prueba el archivo con php -S 127.0.0.1:8000 desde el directorio que lo contiene y abre http://127.0.0.1:8000/formulario.php. Escribe un nombre y observa cómo el servidor procesa la petición POST. El valor se escapa antes de insertarlo en HTML, de modo que un nombre con símbolos especiales no se interpreta como marcado. Para comprender las amenazas que aborda, consulta la guía CSRF de OWASP.

En un sistema real necesitarás además configurar la cookie de sesión (Secure, HttpOnly, SameSite según el caso), límites de tamaño, autenticación y autorización. Si una operación modifica datos, considera también protección ante repetición de solicitudes y transacciones cuando corresponda.

¿Dónde se guardan los datos?

Las variables PHP viven dentro de la ejecución del proceso, pero normalmente no son el lugar donde guardar información duradera de los usuarios. Para persistencia utilizamos una base de datos; para información temporal compartida podemos emplear sesiones y caché; para tareas de larga duración, una cola. En un entorno con varios servidores, los datos de sesión necesitan un almacenamiento que todos los servidores adecuados puedan consultar, o una estrategia de afinidad cuidadosamente gestionada.

Manejo de errores y registros

Un error de validación no es lo mismo que una excepción inesperada. Los errores previstos deben convertirse en respuestas comprensibles, mientras que las excepciones de infraestructura requieren registro, observabilidad y una respuesta que no exponga credenciales ni rutas internas. PHP dispone de excepciones y de las interfaces de PSR-3 para organizar el logging. El objetivo es diagnosticar fallos sin publicar la información sensible del servidor.

Organizar el primer proyecto sin complicarlo en exceso

Una estructura razonable para comenzar separa el punto de entrada público del código de aplicación y de las dependencias instaladas. No es el único diseño válido, pero ayuda a comprender una regla de seguridad importante: el servidor web solo debería exponer los archivos públicos.

mi-aplicacion/
├── public/
│   └── index.php        ← entrada HTTP
├── src/                  ← clases y lógica propia
├── tests/                ← pruebas automatizadas
├── config/               ← configuración sin secretos
├── vendor/               ← dependencias de Composer
├── composer.json
├── composer.lock
└── .env                  ← configuración local, no subir al repositorio

El archivo .env sirve frecuentemente para desarrollo, pero no debe contener secretos que terminen versionados o publicados. En despliegues reales es preferible un administrador de secretos o mecanismos equivalentes del entorno. Añade .env y vendor/ a .gitignore cuando corresponda; conserva un .env.example sin valores sensibles para documentar las variables necesarias.

Composer, Packagist y estándares PSR: el ecosistema profesional

Composer y Packagist

Durante los primeros años de PHP era habitual descargar bibliotecas manualmente y copiar archivos de un proyecto a otro. Hoy ese trabajo lo hacemos principalmente con Composer, que resuelve las dependencias y prepara la carga automática de clases. Los paquetes suelen publicarse en Packagist, el repositorio público más conocido del ecosistema. Composer y Packagist trabajan juntos, pero no son la misma herramienta.

Para hacerse una idea del tamaño de este ecosistema, basta consultar el balance publicado por Packagist el 29 de septiembre de 2026: más de 469.000 paquetes, 5,8 millones de versiones y 200.000 millones de instalaciones acumuladas. Son números que ayudan a entender por qué resulta fácil encontrar componentes maduros para muchas necesidades habituales del desarrollo web.

Conviene interpretar correctamente ese último contador. Una aplicación puede instalar las mismas dependencias cientos de veces en sus procesos de integración y despliegue, por lo que 200.000 millones de instalaciones no equivalen a 200.000 millones de usuarios o proyectos diferentes. Como indicador de actividad del repositorio, sin embargo, la cifra es reveladora.

Veamos algunas operaciones frecuentes: crear un proyecto, añadir una biblioteca, comprobar la configuración y revisar avisos de seguridad de las dependencias.

composer init
composer require monolog/monolog
composer validate
composer audit
composer install --no-dev --prefer-dist --optimize-autoloader

En aplicaciones, guarda composer.json y composer.lock en el repositorio. El segundo archivo fija las versiones resueltas y ayuda a reproducir instalaciones. Para producción suele utilizarse composer install --no-dev, acompañado de pruebas y de un proceso de despliegue controlado; por sí solo ese comando no garantiza que el servidor esté bien configurado.

Autoloading con PSR-4

Otro cambio que se agradece al trabajar en equipo es dejar de añadir require manualmente por todas partes. Con PSR-4, Composer sabe dónde buscar las clases según su namespace. Esta sería una configuración sencilla:

{
  "name": "universodigital/ejemplo-php",
  "require": {
    "php": "^8.5"
  },
  "autoload": {
    "psr-4": {
      "UniversoDigital\\App\\": "src/"
    }
  }
}

Con esa configuración, una clase UniversoDigital\App\Producto se buscaría en src/Producto.php. Después de modificar el mapa de autoloading, ejecuta composer dump-autoload.

Qué son los PSR y qué problema resuelven

Mucho antes de construir una aplicación conviene conocer los estándares PSR publicados por PHP-FIG. PSR-4 describe la carga automática de clases, PSR-3 establece una interfaz de logging, PSR-7 define mensajes HTTP, PSR-15 trata los middlewares y PSR-12 propone reglas de estilo. Son acuerdos que facilitan integrar bibliotecas creadas por equipos distintos.

¿Significa eso que podemos cambiar Laravel por Symfony con un clic? No. Las convenciones comunes reducen las dependencias innecesarias, pero cada framework mantiene componentes y formas de trabajar propias. Aun así, utilizar interfaces conocidas y separar la lógica de negocio de las herramientas concretas facilita mucho el mantenimiento posterior.

Cómo se ejecuta PHP en producción: PHP-FPM, OPcache y nuevos runtimes

El modelo tradicional sigue siendo competitivo

Cuando instalamos PHP en un servidor convencional, una arquitectura muy frecuente es Nginx o Apache → PHP-FPM → aplicación → base de datos o caché. PHP-FPM administra procesos que reciben solicitudes mediante FastCGI. Es un esquema conocido por administradores y proveedores de alojamiento, sencillo de supervisar y suficiente para muchísimos sitios y aplicaciones.

Una de las primeras mejoras que merece la pena revisar es OPcache. Su trabajo consiste en conservar en memoria el código PHP ya compilado, evitando repetir esa tarea en cada petición. No hay que confundirlo con mantener en memoria el estado completo de la aplicación: bajo el modelo habitual de PHP-FPM, las variables ordinarias de una solicitud no se reutilizan automáticamente en la siguiente.

También importa cuántos procesos puede atender el servidor. El parámetro pm.max_children no debe calcularse a ojo: hay que medir el consumo real de memoria de los workers y dejar recursos para el sistema operativo, la base de datos y el resto de servicios. Subirlo sin más puede terminar en intercambio a disco o procesos eliminados por falta de memoria. El JIT, por su parte, puede ayudar en ciertos cálculos, pero rara vez resuelve el cuello de botella de una aplicación que espera a SQL o a una API externa.

FrankenPHP, RoadRunner y Swoole: trabajadores persistentes

Sin embargo, PHP ya no está limitado a ese modelo. Laravel Octane permite utilizar FrankenPHP, RoadRunner o Swoole para mantener la aplicación cargada entre solicitudes. Symfony Runtime facilita integrar distintos entornos de ejecución mediante sus adaptadores. Para aplicaciones con inicializaciones costosas, esta forma de trabajar puede reducir trabajo repetido y mejorar los tiempos de respuesta.

La mejora no es automática. Si la mayor parte del tiempo se pierde consultando una base de datos sin índices o esperando una API remota, conservar la aplicación en memoria no arreglará el problema. Antes de cambiar de runtime conviene medir dónde está realmente el cuello de botella y comparar con la misma carga de trabajo.

Hay además una diferencia que el desarrollador debe tener muy presente: un worker persistente puede conservar estado entre solicitudes. Si guardamos por descuido información del usuario en una propiedad estática o un singleton compartido, ese dato podría terminar apareciendo en otra petición. También pueden crecer las fugas de memoria. Por eso hacen falta limpieza de recursos, reinicios controlados, límites por worker y pruebas de aislamiento. Es una de las advertencias que encontrarás en las guías oficiales de FrankenPHP y Octane.

Si administras tu propio servidor, yo empezaría optimizando PHP-FPM y OPcache. Solo daría el salto a un runtime persistente cuando las métricas mostraran un beneficio real. La sencillez operativa también tiene valor, y a veces es mejor invertir una tarde en corregir consultas SQL que una semana en cambiar la arquitectura.

¿Y los trabajos en segundo plano?

PHP también puede mantenerse ejecutando tareas CLI: colas de trabajos, correo, exportaciones o informes periódicos. Estos procesos necesitan supervisión mediante systemd u otras herramientas, límites de memoria, registros, reintentos y una política clara para recuperarse de fallos. Son aplicaciones perfectamente normales de PHP, aunque su ciclo de vida no sea el de una petición HTTP.

Guía de runtimes PHP modernos: qué son y cuándo utilizarlos

Es habitual leer que PHP «arranca desde cero en cada petición». Esa descripción sirve para entender parte de su historia, pero ya no representa todos los modelos disponibles. Lo correcto es distinguir entre el motor PHP, la interfaz de ejecución (CLI, FPM, embebida, etc.) y el servidor de aplicaciones que gestiona las peticiones, los procesos y sus ciclos de vida. PHP puede ejecutarse en un modelo tradicional por solicitud o permanecer cargado en memoria durante múltiples solicitudes.

FrankenPHP no es únicamente un servidor más rápido

FrankenPHP integra el motor PHP en un servidor basado en Caddy y ofrece dos formas de trabajar: modo clásico, adecuado para muchas aplicaciones PHP existentes, y modo worker, pensado para proyectos capaces de conservar su aplicación en memoria. La integración con Laravel y Symfony está documentada. También ofrece alternativas de empaquetado y despliegue que pueden simplificar determinadas instalaciones, aunque no sustituyen las pruebas de compatibilidad.

Para familiarizarte con sus modos, comienza por la documentación general y la guía de workers. Evita activar un worker persistente en un proyecto heredado sin evaluar cómo gestiona las sesiones, los servicios compartidos y las conexiones de base de datos.

RoadRunner y los procesos persistentes

RoadRunner separa la gestión del servidor —realizada por un proceso en Go— de los workers PHP que ejecutan la aplicación. Al reutilizar workers se puede ahorrar trabajo de inicialización y atender peticiones con una latencia menor bajo ciertas cargas. El ahorro depende del framework, las dependencias y la naturaleza del trabajo. En proyectos Laravel la vía habitual es Octane, que añade convenciones y herramientas para operar sobre estos servidores.

Swoole y OpenSwoole: concurrencia asíncrona

Swoole y OpenSwoole amplían PHP con capacidades de servidores asíncronos, corrutinas y operaciones de red. Son interesantes para protocolos de comunicación, servicios concurrentes y cargas que requieren muchas conexiones, aunque incorporan un modelo de ejecución distinto del de una aplicación tradicional PHP-FPM. No basta con instalar la extensión: hay que estudiar cómo se comportan las operaciones bloqueantes, las bibliotecas de terceros, la memoria y el estado compartido.

¿Y WebSockets, eventos y tiempo real?

PHP puede intervenir en sistemas de mensajería, notificaciones y tiempo real. Por ejemplo, Laravel Reverb proporciona un servidor WebSocket del propio ecosistema Laravel; Symfony Messenger permite enviar mensajes y ejecutar trabajos de forma síncrona o asíncrona con transportes adecuados. No hace falta convertir toda la web en una aplicación persistente para resolver una función de chat o actualizar un tablero en directo.

La trampa de los benchmarks

Para decidir entre runtimes, mide un escenario realista: autenticación, consultas, serialización de respuestas, cachés, errores, consumo de memoria y comportamiento con decenas o cientos de conexiones. Incluye latencias p95/p99, no solamente peticiones por segundo. En un sistema pequeño, PHP-FPM puede ofrecer una relación entre rendimiento y sencillez difícil de mejorar; en otro donde el arranque del framework sea caro, los workers persistentes pueden marcar la diferencia.

En ambos casos, la robustez también es rendimiento: cuenta lo que ocurre cuando un worker agota memoria, se bloquea una dependencia, falla la base de datos o hay que actualizar la aplicación sin interrumpir el servicio. Un servidor que responde rápido hasta que colapsa no está bien optimizado.

Ejemplo práctico: crear una pequeña API REST en PHP

Vamos a construir algo más cercano a una aplicación web. No será una API de producción, sino un ejemplo deliberadamente pequeño para ver cómo PHP recibe una petición, comprueba sus datos y devuelve JSON. Crea una carpeta llamada public y dentro un archivo index.php con el siguiente contenido:

<?php
// Archivo: public/index.php
declare(strict_types=1);

header('Content-Type: application/json; charset=utf-8');

if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    header('Allow: GET');
    http_response_code(405);
    echo json_encode(['error' => 'Método no permitido']);
    exit;
}

$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null || $id < 1) {
    http_response_code(400);
    echo json_encode(['error' => 'Usa un id entero positivo']);
    exit;
}

echo json_encode([
    'id' => $id,
    'nombre' => 'Producto de demostración',
    'precio' => 25.50,
], JSON_THROW_ON_ERROR);

Para probarlo, abre una terminal en el directorio del proyecto, inicia el servidor integrado de PHP y consulta la dirección desde otra terminal o desde el navegador:

php -v
php -S 127.0.0.1:8000 -t public
# En otra terminal:
curl -i "http://127.0.0.1:8000/?id=1"

Si todo está bien, recibirás un objeto JSON con el identificador del producto, su nombre y su precio. Cambia el valor de id por una cadena o elimínalo y comprobarás cómo responde con el estado HTTP 400; utiliza otro método HTTP y devolverá 405. Son detalles sencillos, pero muestran una idea importante: una API también debe saber explicar cuándo una petición no es válida.

No utilices este servidor integrado para publicar una web. El comando php -S está pensado para pruebas locales, tal como advierte el manual de PHP. Si el proyecto crece, necesitaremos autenticación, límites de peticiones, registros, pruebas, persistencia de datos y un servidor apropiado para producción.

Persistencia con PDO y sentencias preparadas

Para guardar y recuperar información, PHP dispone de PDO, una interfaz que permite conectarse con diferentes gestores de bases de datos. En el ejemplo siguiente consultamos un usuario en MySQL mediante parámetros. Damos por hecho que la tabla existe y que $email contiene la dirección que queremos buscar:

<?php
declare(strict_types=1);

$pdo = new PDO(
    'mysql:host=127.0.0.1;dbname=tienda;charset=utf8mb4',
    getenv('DB_USER') ?: '',
    getenv('DB_PASSWORD') ?: '',
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

$consulta = $pdo->prepare(
    'SELECT id, nombre FROM usuarios WHERE email = :email'
);
$consulta->execute(['email' => $email]);
$usuario = $consulta->fetch(PDO::FETCH_ASSOC);

La sentencia preparada evita que el valor de $email se trate como parte del código SQL. Eso ayuda a prevenir la inyección SQL, pero recuerda que los parámetros no sirven para sustituir nombres de tablas o columnas. Si necesitas elegir identificadores dinámicamente, utiliza una lista cerrada de opciones permitidas. Para una aplicación real también habrá que incorporar índices, transacciones y un mecanismo seguro para gestionar credenciales.

Frameworks PHP: Laravel, Symfony, Slim y WordPress

Laravel: productividad para aplicaciones y APIs

Laravel suele gustar a quienes necesitan desarrollar una aplicación completa en poco tiempo sin tener que escoger cada componente por separado. Incluye rutas, autenticación, migraciones, colas, pruebas y Eloquent para trabajar con la base de datos. Esa comodidad es valiosa, pero no exime de entender lo que ocurre por debajo: una consulta N+1 seguirá siendo ineficiente aunque la haya generado un ORM.

Symfony: componentes e integración empresarial

Symfony ofrece otro enfoque muy consolidado, apoyado en componentes reutilizables, inyección de dependencias y una estructura que encaja bien en aplicaciones grandes y mantenidas durante años. Ninguno de los dos frameworks es automáticamente superior: importa más la experiencia del equipo y la forma de organizar el proyecto que una supuesta clasificación de «el mejor».

Microframeworks y CMS

Cuando necesitamos algo más pequeño, Slim permite construir APIs ligeras. Y está también WordPress, que juega en otra categoría: no pretende ser un framework general para cualquier aplicación, sino un gestor de contenidos que resuelve extraordinariamente bien muchos problemas de publicación. Si quieres ver cómo se despliega uno de estos proyectos, puedes consultar nuestra guía de instalación de WordPress en Ubuntu 24.04. La versión PHP utilizada allí responde a ese entorno concreto.

Laravel y Symfony a fondo: cómo elegir y empezar a desarrollar

En cualquier recorrido serio por PHP, Laravel y Symfony merecen un lugar destacado. Los dos ofrecen mucho más que enrutamiento: proporcionan herramientas para organizar el proyecto, trabajar con datos, autenticar usuarios, integrar servicios y automatizar pruebas. No son tecnologías incompatibles; Laravel utiliza componentes Symfony y ambos comparten estándares de PHP, Composer y buena parte de la infraestructura habitual.

Laravel: del primer prototipo a una aplicación de negocio

Cuando tenemos que crear un panel administrativo, un servicio de reservas, una tienda o una plataforma SaaS, repetimos muchas tareas: registro e inicio de sesión, validación, formularios, base de datos, notificaciones, correo y colas. Laravel facilita empezar con esos componentes de forma integrada. Su atractivo no está solamente en escribir menos código, sino en adoptar convenciones que hacen que un proyecto sea reconocible para otros desarrolladores.

Entre sus herramientas fundamentales están Eloquent ORM para modelos y consultas, las migraciones para evolucionar el esquema, Artisan para tareas de consola, Validation, Queues y Cache. Aprende primero a utilizarlas correctamente; un ORM también puede generar consultas deficientes si no vigilamos su funcionamiento.

La guía oficial de instalación de Laravel explica los requisitos y métodos recomendados. Con PHP, Composer y el entorno preparado, estos comandos permiten empezar un proyecto nuevo:

composer global require laravel/installer
laravel new tienda-demo
cd tienda-demo
npm install && npm run build
composer run dev

En un proyecto Laravel ya creado, podemos declarar una ruta muy sencilla que devuelve una respuesta JSON:

<?php
// routes/web.php, dentro de un proyecto Laravel.
use Illuminate\Support\Facades\Route;

Route::get('/saludo/{nombre}', function (string $nombre) {
    return response()->json(['mensaje' => "Hola, {$nombre}"]);
});

Para las interfaces, Blade permite renderizar HTML desde PHP; Livewire aporta interactividad y combina bien con Alpine.js. Si ya trabajas con React, Vue o Svelte, Inertia.js integra esos frontends con el backend sin obligarte a construir dos aplicaciones completamente independientes. Los starter kits oficiales pueden ahorrar el trabajo inicial de autenticación y diseño.

Las herramientas complementarias de Laravel

• Sanctum: autenticación con tokens y aplicaciones SPA.
• Horizon: gestión y observación de colas Laravel basadas en Redis.
• Telescope y Pulse: diagnóstico, actividad y métricas de la aplicación.
• Octane: ejecución de aplicaciones con servidores y workers persistentes.
• Reverb: WebSockets y eventos en tiempo real.
• Scout: integración con motores de búsqueda.
• Pennant: activación gradual de funcionalidades mediante flags.
• Sail: entorno local Docker; Forge, Cloud y Vapor ofrecen opciones comerciales distintas de operación y despliegue.

Estas herramientas no deben convertirse en una lista de instalaciones obligatorias. Empieza con rutas, modelos, migraciones, vistas y pruebas. Incorpora colas, WebSockets, observabilidad o workers persistentes cuando exista una necesidad real.

Symfony: arquitectura por componentes y proyectos mantenibles

Symfony puede usarse como framework completo o como una colección de componentes independientes. Su especialidad es ofrecer piezas muy definidas —peticiones HTTP, enrutamiento, servicios, seguridad, consola— que ayudan a organizar aplicaciones con requisitos complejos. Esa modularidad explica que otros proyectos PHP utilicen sus componentes sin ser aplicaciones Symfony.

La instalación oficial y la Symfony CLI permiten crear un proyecto:

symfony new portal-demo --webapp
cd portal-demo
symfony server:start

La opción --webapp incluye dependencias habituales de un sitio web; para una API pequeña podemos crear un esqueleto mínimo. Un controlador Symfony que devuelve el mismo saludo en JSON utiliza atributos y componentes HTTP:

<?php
// src/Controller/SaludoController.php
namespace App\Controller;

use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Attribute\Route;

final class SaludoController
{
    #[Route('/saludo/{nombre}', name: 'saludo', methods: ['GET'])]
    public function saludar(string $nombre): JsonResponse
    {
        return new JsonResponse(['mensaje' => "Hola, {$nombre}"]);
    }
}

Los servicios e inyección de dependencias ayudan a mantener lógica de negocio fuera de los controladores; Twig construye vistas; y Doctrine es una opción habitual para persistencia, entidades y migraciones. Para empezar sin improvisar una arquitectura, recomiendo el curso oficial Symfony Fast Track.

Componentes Symfony que conviene conocer

Una de las ayudas que encontrarás durante el desarrollo es el Symfony Profiler. Permite inspeccionar información de las peticiones, consultas, memoria y tiempos de ejecución para investigar problemas sin trabajar a ciegas. La siguiente captura procede de la documentación oficial; la interfaz puede variar entre versiones.

• HttpFoundation, Routing y HttpKernel: peticiones, enrutamiento y ejecución.
• Security y Validator: autenticación, permisos y validación.
• Messenger: colas y mensajes; Workflow: estados y transiciones.
• Cache, HttpClient y Serializer: caché, redes y transformación de datos.
• Console, Runtime, Symfony UX y API Platform: CLI, ejecución, frontend y APIs.

Laravel frente a Symfony: comparativa práctica

Para aprender no necesitas estudiar los dos a la vez. Elige uno, construye un proyecto con usuarios, datos, formularios y pruebas, y después examina el otro. Laravel suele ser un punto de entrada cómodo cuando quieres construir una aplicación completa; Symfony permite estudiar con detalle la composición de sus capas. Ninguno compensa un diseño deficiente o unas consultas SQL ineficientes.

Otros frameworks y plataformas PHP

Además de los dos referentes, existen Slim, CodeIgniter, Yii, CakePHP, Laminas, Phalcon y API Platform. Sus enfoques y requisitos son diferentes: examina mantenimiento y soporte antes de elegir.

Por otra parte, WordPress, Drupal, Joomla, Magento Open Source y Nextcloud son aplicaciones o plataformas PHP con objetivos concretos. No debemos confundir un lenguaje, un framework, un CMS y un runtime, aunque los cuatro formen parte del mismo ecosistema.

Mapa del ecosistema PHP: bibliotecas, bases de datos y herramientas de equipo

Una ventaja de elegir PHP hoy es que rara vez tendremos que resolver solos los problemas habituales del backend. Hay herramientas maduras para acceso a datos, HTTP, correo, generación de documentos, pagos, observabilidad y pruebas. Sin embargo, tener muchos paquetes no significa que todos sean seguros o estén mantenidos: antes de instalar una biblioteca revisa su documentación, versiones, mantenimiento y avisos de seguridad.

Bases de datos, persistencia y caché

PHP trabaja con MySQL, MariaDB, PostgreSQL y SQLite, entre otros motores. La extensión PDO proporciona una interfaz común; Doctrine DBAL añade abstracciones y Doctrine ORM permite mapear entidades a tablas. En Laravel es muy habitual Eloquent.

Para respuestas repetidas o sesiones compartidas podemos utilizar Redis; no sustituye por defecto a una base de datos relacional, sino que desempeña papeles de caché, colas, datos temporales y otras estructuras especializadas. También existen soluciones como Memcached. Las consultas deben diseñarse con índices adecuados: elegir un ORM no elimina la necesidad de comprender SQL.

Cliente HTTP, logging y mensajería

Al comunicarnos con servicios externos, Guzzle es un cliente HTTP conocido y Symfony HttpClient ofrece otra implementación madura. Para registrar fallos y eventos podemos utilizar Monolog, que implementa PSR-3. Para mensajes y colas están Symfony Messenger, las colas de Laravel y sistemas externos como RabbitMQ, si la arquitectura lo necesita.

Pruebas, análisis estático y formato

No es necesario instalar todo esto en el primer proyecto. Una buena base suele ser Git, Composer, un depurador, un framework de pruebas y un analizador estático. Después se añaden herramientas especializadas. También merece la pena conocer Git y los sistemas de integración continua, como GitHub Actions o GitLab CI/CD.

Frontend y activos: PHP no vive aislado de JavaScript

Para proyectos actuales también encontraremos Vite como herramienta de empaquetado de frontend, Tailwind CSS para estilos y bibliotecas JavaScript según las necesidades del sitio. En Laravel, la propia documentación explica cómo combinar Blade y Livewire o Inertia con React, Vue y Svelte. Symfony también admite distintas estrategias de frontend. La integración no exige escribir todo en un único lenguaje.

Extensiones PHP y acceso a servicios del sistema

Además de paquetes Composer, PHP dispone de extensiones que permiten utilizar cifrado, archivos ZIP, imágenes, internacionalización, bases de datos y protocolos de red. Entre las más habituales están cURL, Intl, mbstring, Sodium y las extensiones de PDO. No confundas un paquete PHP distribuido por Packagist con una extensión nativa del motor: se instalan y mantienen de maneras distintas.

Seguridad y calidad: la arquitectura importa más que el eslogan

En seguridad también arrastramos viejos prejuicios. Hace años circulaban muchas aplicaciones PHP que mezclaban consultas SQL con variables recibidas directamente del navegador, pero ese código sería peligroso en cualquier lenguaje. Hoy disponemos de sentencias preparadas, funciones de escape, bibliotecas de autenticación y herramientas de análisis; lo importante es emplearlas correctamente y mantener el software actualizado.

• SQL injection: usa sentencias preparadas o un ORM correctamente configurado; evita concatenar datos de usuario en consultas.
• XSS: escapa la salida conforme al contexto (HTML, atributos, JavaScript, URL); para contenido HTML usa funciones adecuadas como htmlspecialchars() y no confíes solo en la validación de entrada.
• CSRF: protege operaciones que cambian estado, configura cookies y comprueba el origen cuando proceda.
• Contraseñas: utiliza password_hash() y password_verify(), nunca hashes rápidos creados manualmente para almacenar contraseñas.
• Sesiones: cookies Secure, HttpOnly y SameSite según la aplicación; regenera el identificador al iniciar sesión y administra correctamente la expiración.
• Archivos y dependencias: restringe tipos, tamaños, destinos y permisos de las subidas. Audita dependencias y evita librerías abandonadas.
• Autorización: valida permisos del lado servidor para cada recurso. Autenticación y autorización son controles distintos.

Dos operaciones habituales merecen especial atención: escapar texto antes de mostrarlo en HTML y utilizar funciones diseñadas expresamente para almacenar y verificar contraseñas. Por ejemplo:

<?php
declare(strict_types=1);

$texto = $_GET['nombre'] ?? '';
if (!is_string($texto)) {
    $texto = '';
}
echo htmlspecialchars($texto, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');

$hash = password_hash($password, PASSWORD_DEFAULT);
$esValida = password_verify($passwordRecibida, $hash);

Estos fragmentos son ejemplos de dos situaciones distintas; las variables de contraseña tendrían que proceder de un formulario y de un flujo de autenticación bien diseñado. Tampoco debemos utilizar htmlspecialchars() como solución para cualquier salida: escapar HTML, generar JavaScript y construir una URL son contextos diferentes.

Análisis estático, estilo y pruebas

Para evitar que los fallos lleguen al usuario, conviene automatizar la comprobación del código. PHPUnit y Pest permiten escribir pruebas; PHPStan y Psalm detectan problemas de tipos, llamadas incorrectas y posibles errores antes de ejecutar la aplicación. Son herramientas muy útiles incluso cuando heredamos un proyecto antiguo que no dispone todavía de pruebas.

composer require --dev phpunit/phpunit phpstan/phpstan
vendor/bin/phpunit
vendor/bin/phpstan analyse src --level=5
composer audit

Instalar herramientas no sustituye a escribir pruebas ni a preparar una integración continua. Lo razonable es empezar por los módulos más críticos, ampliar gradualmente la cobertura y revisar las dependencias con composer audit. Una prueba que no comprueba el comportamiento real aporta bastante menos de lo que su porcentaje de cobertura sugiere.

Producción, observabilidad y actualizaciones

Cuando el proyecto se publica, necesitamos ver qué está ocurriendo. Registrar errores, tiempos de respuesta, consultas lentas y saturación de procesos ayuda a saber si el problema está en PHP, en la base de datos o en un servicio externo. En un servidor compartido por varias aplicaciones, esa información evita muchos cambios a ciegas.

; Ajustes orientativos, no valores universales
display_errors = Off
log_errors = On
opcache.enable = 1
; dimensionar OPcache y PHP-FPM según carga y memoria real

Los ajustes anteriores son orientativos: cada servidor necesita su propia configuración. Prepara despliegues reproducibles, conserva un procedimiento de reversión y prueba las actualizaciones de PHP con antelación. Esto último es especialmente importante en WordPress, donde un plugin abandonado puede no ser compatible con una versión que el núcleo sí soporta.

PHP frente a JavaScript/TypeScript, Python, Java, C#, Go, Ruby y Rust

Llegados a este punto, la pregunta natural es: si PHP funciona, ¿por qué elegir Node.js, Python, Java, C# o Go? Porque cada tecnología aporta herramientas y compromisos distintos. No podemos decidir únicamente por la sintaxis ni comparar dos lenguajes mediante una prueba de «hola mundo». Interesan la experiencia del equipo, el tipo de aplicación, el rendimiento real, el alojamiento disponible y cuánto costará mantener el sistema dentro de unos años.

PHP vs. Node.js y TypeScript

Si tu equipo ya utiliza TypeScript en el navegador, trabajar con Node.js en el servidor permite compartir lenguaje y ciertos modelos de datos. Su enfoque asíncrono resulta práctico para conexiones concurrentes, streaming y servicios en tiempo real. PHP, por su parte, encaja muy bien en aplicaciones basadas en peticiones HTTP, formularios, catálogos y operaciones sobre una base de datos. Ambos pueden escalar: importa cómo se diseñan y dónde se encuentra la carga.

PHP vs. Python

Python es difícil de ignorar cuando el proyecto necesita modelos de aprendizaje automático, análisis de datos o bibliotecas científicas. Django y FastAPI también son opciones consolidadas para construir servicios web. Si, en cambio, la mayor parte del trabajo consiste en gestionar contenidos, ventas, usuarios y procesos de negocio, PHP puede resolverlo con gran productividad. El contexto es más importante que la popularidad general de cada lenguaje.

PHP vs. Java, Kotlin y C#

Java, Kotlin y C# cuentan con ecosistemas empresariales enormes y herramientas sólidas para aplicaciones complejas. Spring y ASP.NET Core permiten organizar servicios de gran tamaño, aplicar políticas corporativas y aprovechar equipos especializados. PHP puede resultar más directo para ciertos proyectos web, aunque no sería sensato cambiar una plataforma JVM o .NET que ya cumple sus objetivos solo para simplificar el lenguaje utilizado.

PHP vs. Go y Rust

Go suele encajar muy bien en herramientas de infraestructura y servicios de red; Rust añade garantías interesantes cuando importan especialmente la memoria y el control de recursos. Podemos utilizar PHP para el portal web y reservar otro lenguaje para un servicio de procesamiento intensivo, aunque cada tecnología adicional introduce despliegues, dependencias y mantenimiento que hay que justificar.

¿Qué significa el rendimiento en un proyecto real?

Cuando alguien afirma que un lenguaje es «diez veces más rápido», lo primero que preguntaría es qué se midió. Una respuesta vacía no se parece a una operación que consulta datos, aplica reglas de negocio y llama a un servicio externo. Para comparar de forma útil debemos reproducir la misma carga, con datos, hardware y configuración equivalentes, y observar latencia, memoria, errores y coste operativo. Las diferencias que de verdad importan aparecen en ese escenario.

Documentación oficial de los lenguajes y frameworks comparados

Si estás considerando otro lenguaje, lo más útil es probarlo utilizando sus propias guías y no quedarte con comparativas de terceros. Estas son las fuentes primarias de las alternativas mencionadas:

No interpretes el orden de esta tabla como un ranking. Cada comunidad construye herramientas distintas y la mejor decisión depende de la aplicación concreta. Si vienes de otros lenguajes, te puede interesar nuestro artículo sobre tipos y clasificaciones de lenguajes de programación, que sirve como punto de partida para esa comparación.

Cuándo elegir PHP y cuándo preferir otra alternativa

Si tuviera que desarrollar hoy un portal de contenidos, una tienda, un panel de administración o una API empresarial convencional, PHP estaría entre mis primeras opciones, especialmente si el equipo conoce Laravel, Symfony o WordPress. Existe documentación abundante, es fácil conseguir alojamiento y el ecosistema ofrece piezas maduras para la mayoría de las necesidades de este tipo de aplicación.

Elegiría otra alternativa cuando el proyecto lo pidiera: Python si las bibliotecas de IA y análisis de datos fueran centrales, TypeScript si compartir el lenguaje en todo el producto simplificara de verdad el desarrollo, o Go y Rust si estuviéramos construyendo determinados servicios de infraestructura. No se trata de que PHP no pueda hacer otras cosas, sino de reconocer dónde cada opción tiene ventajas reales.

También distinguiría una decisión nueva de una reescritura. No es lo mismo empezar desde cero que mantener una aplicación PHP que lleva años funcionando y atendiendo clientes. Antes de reemplazarla, mediría sus problemas, revisaría las posibilidades de actualización y calcularía el riesgo de volver a desarrollar funciones que ya están probadas. Reescribir por moda suele salir bastante más caro de lo que parece.

En pocas palabras, empezaría por los requisitos y las capacidades del equipo; después revisaría bibliotecas, despliegue, rendimiento y mantenimiento. Si aún existieran dudas importantes, construiría una prueba de concepto y mediría. Ese trabajo suele aportar más información que semanas de discusiones sobre cuál lenguaje es «el mejor».

Ruta de aprendizaje: de cero a tu primera aplicación PHP profesional

La mejor forma de aprender un lenguaje no es leer todos sus manuales de principio a fin. Después de comprender los conceptos principales, necesitas construir algo que resuelva un problema real y enfrentarte a los errores que aparecen por el camino. Te propongo una ruta gradual que no exige instalar un framework desde el primer día.

Etapa 1. Fundamentos de la Web y PHP

Aprende HTML y formularios; entiende las diferencias entre cliente y servidor, los métodos HTTP, los códigos de respuesta y el formato JSON. En PHP practica variables, operadores, arrays, funciones, condicionales, bucles y archivos. Crea una página de presentación que genere HTML y un script de terminal que procese un archivo CSV. Apóyate en la ruta de aprendizaje web de MDN y el tutorial oficial de PHP.

Etapa 2. Formularios, validación, sesiones y base de datos

Construye un pequeño catálogo de productos. Primero guárdalos en memoria o en un archivo de pruebas; después utiliza SQLite con PDO para almacenar productos y categorías. Implementa altas, consultas, modificaciones y bajas (CRUD), siempre con sentencias preparadas. Añade validación, mensajes de error, autenticación y verificación de permisos sobre cada recurso.

Etapa 3. Composer, orientación a objetos y organización del código

Separa el punto de entrada de la lógica de negocio. Utiliza namespaces, PSR-4 y Composer; crea clases para entidades, servicios y repositorios. Escribe pruebas con PHPUnit o Pest y configura PHPStan. No hace falta introducir una arquitectura hexagonal completa en un CRUD de aprendizaje: comienza por separar responsabilidades y por entender cómo probar cada una.

Etapa 4. Una aplicación con Laravel o Symfony

Elige uno de los dos frameworks. Repite tu catálogo utilizando enrutamiento, migraciones, validación y un ORM. Añade usuarios, roles, paginación, búsquedas y pruebas HTTP. En Laravel puedes seguir Laravel Learn; en Symfony, el Fast Track oficial. Compara el trabajo que te ha ahorrado el framework con lo que antes tenías que implementar manualmente.

Etapa 5. Preparar el despliegue

Versiona el proyecto con Git, ejecuta pruebas de forma automática y despliega en un entorno aislado. Configura HTTPS, secretos, registros, copias de seguridad y un procedimiento de actualización y reversión. Practica primero con un VPS o contenedor de pruebas: el primer despliegue no debería hacerse sobre un servidor con datos importantes.

Etapa 6. Rendimiento y arquitectura cuando de verdad importen

Con una aplicación funcional, añade mediciones de latencia y memoria, comprueba consultas lentas, utiliza cachés si se justifican y traslada tareas pesadas a colas. Solo después evalúa Octane, FrankenPHP o RoadRunner. Así aprenderás a reconocer un problema que sí necesita otra arquitectura, en lugar de instalar tecnologías sin conocer sus efectos.

Proyecto integrador recomendado: una pequeña tienda con API

Como ejercicio completo propondría una tienda con catálogo, almacén, usuarios y pedidos. Primero crea el CRUD y una API JSON; después agrega roles de administrador y cliente, control de existencias, sesiones, pruebas, búsquedas y generación de un informe. No hace falta integrar pagos reales para empezar. Este ejercicio recorre casi todas las piezas del desarrollo web: HTTP, PHP, SQL, seguridad, arquitectura, frontend y despliegue.

Documenta cómo instalarlo, ejecutarlo y probarlo. Una aplicación sencilla bien terminada, con README, migraciones y pruebas reproducibles, enseña mucho más que diez tutoriales empezados y abandonados.

De la computadora local a producción: despliegue, rendimiento y mantenimiento

Aprender a programar PHP y aprender a operar una aplicación PHP son habilidades relacionadas, pero no idénticas. Cuando un sitio comienza a recibir usuarios reales aparecen exigencias nuevas: copias de seguridad, certificados TLS, capacidad, logs, alertas, cambios de esquema y recuperación ante errores. La madurez de PHP se nota precisamente en que existen procedimientos y herramientas bien conocidos para resolverlas.

Arquitectura de referencia para una aplicación convencional

Un punto de partida razonable es Nginx o Apache, PHP-FPM con OPcache, una base de datos y un sistema de copias de seguridad. Para funcionalidades especializadas podemos agregar Redis como caché, un worker de cola y un sistema de almacenamiento de archivos. No añadas esos servicios hasta que cumplan una función clara: cada componente adicional aumenta el trabajo de monitorización, actualización y recuperación.

Enlaces de referencia: Nginx, Apache HTTP Server, Caddy, PHP-FPM, OPcache y imágenes oficiales PHP para contenedores.

Lista de comprobación antes de exponer el servicio

• Publicar únicamente la carpeta web (public/ u otra prevista por el framework), nunca los archivos de configuración o vendor/.
• Utilizar HTTPS, cookies adecuadas, cabeceras de seguridad y límites razonables de petición y subida de archivos.
• Aplicar el principio de mínimo privilegio a usuarios del sistema, directorios, base de datos y claves.
• Gestionar secretos fuera del repositorio, sin imprimirlos en respuestas HTTP ni logs.
• Instalar dependencias con versiones controladas, actualizar PHP y ejecutar composer audit.
• Preparar migraciones de base de datos con una estrategia de reversión y copias verificadas.
• Registrar errores, tiempos de respuesta y saturación de PHP-FPM, workers, caché y base de datos.
• Ejecutar pruebas automáticas y prever recuperación ante fallos, reinicios y despliegues fallidos.

La lista OWASP Top 10 y las OWASP Cheat Sheets ofrecen referencias independientes de cualquier lenguaje para revisar autenticación, autorización, control de entradas y otras amenazas.

Rendimiento: medir antes de optimizar

Cuando una web se vuelve lenta, la causa puede estar en el código PHP, pero también en consultas sin índices, un pool PHP-FPM saturado, bloqueos de I/O, un servicio externo, cachés mal configuradas o una página que descarga demasiados recursos. Empieza por reproducir el problema y medir su contribución a la latencia. Consulta métricas p50/p95/p99, consultas lentas, consumo de memoria, tiempos de CPU y fallos bajo carga.

Para analizar el servidor utiliza registros y métricas; cuando haga falta un perfilado detallado considera Blackfire o herramientas de profiling compatibles con la plataforma. Para cargas HTTP puedes utilizar herramientas como k6, siguiendo sus manuales y sin bombardear sitios ajenos. Los benchmarks útiles reproducen operaciones reales y describen hardware, configuración, tamaño de datos y metodología.

Monitorización y operaciones

En un proyecto que crece conviene reunir logs, métricas y trazas con identificadores de solicitud. OpenTelemetry proporciona estándares y herramientas de instrumentación; Prometheus y Grafana son opciones conocidas para métricas y visualización. No necesitas desplegar toda esta infraestructura para un sitio pequeño, pero sí saber qué pregunta debes responder cuando un usuario reporta lentitud o errores.

Finalmente, define quién actualiza PHP y sus extensiones, quién aplica migraciones, cómo se revierte un despliegue y cómo se recuperan los datos si algo falla. La calidad de una aplicación web no termina cuando funciona en la máquina del desarrollador.

Preguntas frecuentes sobre PHP

¿PHP está muerto en 2026?

No. Mantiene una presencia importante en la Web, recibe actualizaciones y tiene un ecosistema de herramientas activo. Lo que sí ha cambiado es la competencia: PHP ya no es la única opción sencilla para crear un backend moderno, y eso es positivo.

¿PHP 8.5 es mejor que PHP 8.3 o 8.4?

PHP 8.5 incorpora características que no están en las versiones anteriores, pero la versión más reciente no siempre es la mejor elección inmediata para un servidor existente. Hay que comprobar el soporte de extensiones, frameworks y plugins, además del calendario de mantenimiento de cada rama.

¿Necesito Laravel para programar una API?

No. Podemos crear una API directamente con PHP, como acabamos de ver. Laravel, Symfony o Slim son útiles cuando necesitamos herramientas comunes, organización del proyecto y un mantenimiento más sencillo a medida que aumenta su complejidad.

¿PHP puede ejecutar aplicaciones persistentes y servicios de alto rendimiento?

Sí. FrankenPHP, RoadRunner y Swoole permiten distintos modelos de ejecución persistente y Laravel Octane facilita usarlos. Se pueden obtener mejoras importantes en ciertos proyectos, siempre que se gestione bien el estado entre peticiones y se mida el resultado.

¿Puedo utilizar PHP junto con JavaScript o Python?

Por supuesto. Es habitual desarrollar la interfaz con JavaScript y mantener el backend en PHP. Si una parte del sistema necesita bibliotecas especializadas de Python o un servicio en Go, podemos integrarlos mediante HTTP, mensajes o tareas en segundo plano. No es obligatorio escribir todas las piezas en el mismo lenguaje.

Conclusión: una herramienta madura que merece juzgarse por lo que ofrece hoy

Después de revisar sus características, sus cifras y las alternativas, creo que la conclusión es bastante clara: PHP sigue siendo una herramienta plenamente válida para desarrollar software web. Su mayor fortaleza no es ganar todas las comparaciones de velocidad, sino combinar años de experiencia, bibliotecas maduras, facilidad de despliegue y un lenguaje que ha seguido evolucionando.

¿Significa que todo proyecto web debería escribirse en PHP? Desde luego que no. Pero tampoco tiene sentido descartarlo por recuerdos de PHP 5 o por ejemplos de mal código. Si hoy tienes que decidir con qué construir tu próximo backend, míralo tal como es en 2026, compara los requisitos reales y elige con criterio. Ese es un argumento mucho más sólido que repetir que un lenguaje está muerto.

Fuentes oficiales y documentación recomendada

• Manual oficial de PHP en español, sintaxis, seguridad y extensiones.
• Novedades oficiales de PHP 8.5 y ciclo de soporte de versiones.
• W3Techs: lenguajes de servidor por clasificación de sitios (datos dinámicos; fecha de consulta 11/10/2026).
• Packagist: estadísticas públicas de instalaciones (JSON) y balance oficial de septiembre de 2026.
• Documentación de Composer y recomendaciones PSR de PHP-FIG.
• Laravel Octane, Symfony Runtime y worker mode de FrankenPHP.
• OWASP Cheat Sheet Series, recomendaciones de seguridad aplicables a cualquier backend.
• En Universo Digital: lenguajes de programación: tipos y clasificaciones, editores e IDE y instalación de Nextcloud en un VPS.

Nota: las estadísticas de W3Techs y Packagist cambian con el tiempo. Hemos indicado las fechas y enlazado las fuentes originales para que puedas consultar los datos actualizados. Ninguna de esas métricas mide por sí sola la cantidad de programadores ni la elección de lenguaje en los proyectos nuevos.